Re: DefaultTime2Retain Negotiation during Discovery Session

[William Studenmund <wrstuden@xxxxxxx>]

On Aug 20, 2007, at 12:11 PM, Paul Hughes wrote:

> I think it's legal to terminate a login if a proposed key is not  
> answered in the next login request/response (with exceptions for  
> Boolean negotiations having optional responses).  I don't think  
> RFC3720 states this explicitly, but this seems to indicate that  
> initiators and targets should not delay answering a proposed key:
>
> 5.2.  Text Mode Negotiation
>
>   A target or initiator SHOULD NOT use a Text or Login Response or  
> Text
>   or Login Request with no data segment (DataSegmentLength 0) unless
>   explicitly required by a general or a key-specific negotiation rule.
>
> My interpretation is that DefaultTime2Retain requires an answer and  
> does not require an empty PDU request/response, therefore the  
> acceptor must answer in the next login request/response.

In the example we're talking about, I think terminating negotiation  
would be fine.

The thing though is that the text above is a SHOULD NOT, not MUST NOT.  
So there _could_ be a good reason for delaying. I can think of one,  
but I admit it's a corner case.

Say the initiator has made key offers to the target which the target  
hasn't responded to. Say the target then offers a key, but in order to  
answer, the initiator needs to know the answer to the offers it made.   
In this case, it seems appropriate for the initiator to send an empty  
PDU, so that the target can answer the offers the initiator made (and  
the target didn't answer last pass).

I admit that's a corner case. And we could have a real problem if both  
sides want the answer from the other to respond. I also can't see why  
we'd run into this with the current set of keys. The only explicit  
tiering we have is with the marker keys, and the initiator can offer  
both "do markers" and "markers are at X" in one offer, then the target  
can answer yes or no on markers and "Irrelevant" for the interval if  
it says no.

So I think an immediate terminate is OK, and waiting for a few round  
trips is OK too.

As an aside I wonder if the initiator implementation is getting  
confused by the offer of 0 (which is PERFECTLY VALID) and internally  
overloading 0 with "nothing to do." Ram, can you tell is which  
initiator is doing this? It's OK if you can't.

Take care,

Bill


_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips