Hi Yoav, On Sun, May 24, 2009 at 3:38 PM, Yoav Nir <y...@checkpoint.com> wrote:
> 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 > If we think we are going to allow IKE_AUTH without CHILD SA, i feel notification of IKE_AUTH_NO_CHILD_SA type will be better because VIDs are limited to proprietary use and if any implementation want to support this extension for their products, it can choose a VALUE value for this notification and can update to a new value when IANA assigns it. http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-10 is good example of it. Thanks, Raj
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
