The change is sufficient OK about the status (rather than error) type
OK about using a new registry (though I still think you need to allocate the "locally meaningful name" and some space for private use) Thanks Yoav ________________________________________ From: Vijay Devarapalli [vi...@wichorus.com] Sent: Thursday, May 28, 2009 01:02 To: Yoav Nir; ipsec@ietf.org Subject: Re: [IPsec] Some comments about redirect Hello, On 5/27/09 12:36 AM, "Yoav Nir" wrote: > Hi. > > I've read through the draft again, and here are a few comments: > > Section 3 has the following line: > > If the > IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload, > the responder MUST NOT send the REDIRECT payload to the VPN client. > > > This IMO should apply to all variations, not just to redirect during the > Initial exchange. We could add one sentence at the end of the paragraph. The new one would be The VPN client indicates support for the IKEv2 redirect mechanism and the willingness to be redirected by including a REDIRECT_SUPPORTED notification message in the initial IKE_SA_INIT request. If the IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload, the responder MUST NOT send the REDIRECT payload to the VPN client. This is applicable to all REDIRECT scenarios described in this document. Is this is sufficient? > I'm wondering if the REDIRECT notification type should not be allocated from > the error range. It makes more sense, since it always fails the exchange (or > at least part of it - the child SA in the IKE_AUTH exchange) I don't think the REDIRECT is an error message. In some cases, you have to delete the IKEv2 SA. Then there is the gateway-initiated redirect in the middle of a session. > Section 10 sets up an IANA registry for identity types. Couldn't we just reuse > the "IKEv2 Identification Payload ID Types"? There's already IPv4, IPv6 and > FQDN, and additionally KEY_ID for locally meaningful names and a range of > private use IP addresses. Why set up a new registry for the same thing? In addition to what Tero said, I think the current registry "IKEv2 Identification Payload ID Types" explicitly refers to the ID payload. It doesn't say "ID Types". If it had said "ID types", it could have been used for the REDIRECT payload. Vijay Scanned by Check Point Total Security Gateway. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
