Hi Raj On Thursday, May 21, 2009 9:44 PM, Raj Singh wrote: > Hi Yoav, > > 1. In section5, why we need N[ADDITIONAL_TS_POSSIBLE] when we want > to create child sa? We don't. That comes from (note careful enough) cut-and-paste. Good catch. > 2. Also, please mention clearly in draft that what should be the > behavior of responder if a faulty initiator sends modified > IKE_AUTH request, even if responder has not send IKE_AUTH_NO_CHILD > VID payload. There can be two reasons why a certain implementation has not sent the VID: 1. The responder does not support this extension. In that case, I can't specify any behavior for it, and it should send an INVALID_SYNTAX. 2. It does support this extension, but the administrator has deliberately turned it off. In that case, I think the responder should respond exactly as if it didn't support the extension at all, and reply with an INVALID_SYNTAX. I'll add a line to the draft saying this explicitly. > 3. Also, why its a VID payload, Notify suits better. Because a third > party client will want to connect to some other server. Please give > justification for IKE_AUTH_NO_CHILD to be a VID.
Section 3.12 of -bis document says "A Vendor ID payload MAY announce that the sender is capable of accepting certain extensions to this protcol..." Using a VID has one advantage over a Notify, in that you don't need IANA to allocate a value. With a Notify, I would not be able to get a number from IANA until the document was ready for publication which can take over a year. Implementations that want to support this would need to use a temporary private use notify type, and then protect it with a VID payload (which would not be interoperable, because every vendor would choose a different value and VID). After the document is published, a new version of the product can use a IANA-assigned notify type, but because different products are out there, you need to support for a long time the old private-use type with its VID. Doing it all with VID is simpler and allows continuity between draft and RFC implementations. In IKEv1 it was common to use VIDs to indicate support for an externsion. See for example, RFC 3947. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
