|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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 NegotiationA target or initiator SHOULD NOT use a Text or Login Response or Textor 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