Hello, There at least three people who think that the IKE_AUTH response message should itself contain the REDIRECT payload. I went through the email exchange between Fan and Tero. There was no new information that came out of that discussion for me to make this change in the draft.
Does any one else have an opinion? Otherwise I suggest the WG chairs to make a call on this. Both solutions, 1) sending a REDIRECT payload in the IKE_AUTH response 2) sending a NO_ADDITIONAL_SAS in the IKE_AUTH response followed by a REDIRECT message, would work. Vijay 2009/2/26 Yaron Sheffer <[email protected]>: > <WG chair hat off> > > I join Yoav and Fan in supporting this draft, even in its current form. > However I also agree with them that the protocol will be cleaner (and > subsequently, implementations will be simpler), if we allow redirection in > IKE_AUTH, specifically only in the last message of the exchange. > > Thanks, > Yaron > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> fan zhao >> Sent: Thursday, February 26, 2009 3:58 >> To: Yoav Nir >> Cc: IPsecme WG >> Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 >> >> Hi, >> >> I am ok with moving this draft forward. However, I strongly prefer >> allowing >> redirection in the IKE_AUTH as well. As you may know, last week >> on the 3GPP SA2 meeting, the SA2 working group adopted the solution >> that uses the IKEv2 signaling message for gateway redirection/reallocation >> when the mobile terminal performs attach. >> >> Sincerely, >> fan >> >> >> >> On Wed, Feb 25, 2009 at 5:02 AM, Yoav Nir <[email protected]> wrote: >> > I support advancing this. >> > >> > I preferred allowing the redirect in IKE_AUTH as well, but it seems like >> the group consensus went against that. >> > >> > One textual comment: since we have section 7 describing a symmetric case >> (redirect by either peer), section 6.1 should be chagned to reflect that >> the REDIRECT_SUPPORTED may be in either or both of the request and reply >> of the Initial exchange, and perhaps a picture can be added to section 7. >> > >> > Even without this, the text is clear and useful. >> > >> >> -----Original Message----- >> >> From: [email protected] [mailto:[email protected]] >> >> On Behalf Of Yaron Sheffer >> >> Sent: Wednesday, February 25, 2009 2:34 PM >> >> To: IPsecme WG >> >> Subject: Re: [IPsec] WG Last Call: >> >> draft-ietf-ipsecme-ikev2-redirect-04 >> >> >> >> This is a reminder that we are having a last call for the >> >> Redirect document. Even if you support advancing this >> >> document, but have no other comments, please state your >> >> opinion on the list. >> >> >> >> Thanks, >> >> Yaron >> >> >> >> > -----Original Message----- >> >> > From: [email protected] >> >> [mailto:[email protected]] On Behalf >> >> > Of Yaron Sheffer >> >> > Sent: Monday, February 16, 2009 11:46 >> >> > To: IPsecme WG >> >> > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 >> >> > >> >> > This is a 2 week working group last call for >> >> draft-ietf-ipsecme-ikev2- >> >> > redirect-04. The target status for this document is >> >> Proposed Standard. >> >> > >> >> > Please send your comments to the ipsec list by March 2, 2009, as >> >> > follow- ups to this message. >> >> > >> >> > Please clearly indicate the position of any issue in the Internet >> >> > Draft, and if possible provide alternative text. Please >> >> also indicate >> >> > the nature or severity of the error or correction, e.g. major >> >> > technical, minor technical, nit, so that we can quickly judge the >> >> > extent of problems with the document. >> >> > >> >> > The document can be accessed here: >> >> > http://tools.ietf.org/html/draft-ietf- >> >> > ipsecme-ikev2-redirect-04. >> >> > >> >> > Please note that one issue is currently open against this draft: >> >> > http://tools.ietf.org/wg/ipsecme/trac/ticket/82. >> >> > >> >> > Thanks, >> >> > Yaron >> >> > >> >> > Email secured by Check Point >> >> > _______________________________________________ >> >> > IPsec mailing list >> >> > [email protected] >> >> > https://www.ietf.org/mailman/listinfo/ipsec >> >> > >> >> > Scanned by Check Point Total Security Gateway. >> >> > >> >> > Scanned by Check Point Total Security Gateway. >> >> >> >> Email secured by Check Point >> >> _______________________________________________ >> >> IPsec mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >> Scanned by Check Point Total Security Gateway. >> >> >> >> Scanned by Check Point Total Security Gateway. >> >> >> > Email secured by Check Point >> > _______________________________________________ >> > IPsec mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> _______________________________________________ >> IPsec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. >> >> Scanned by Check Point Total Security Gateway. > > Email secured by Check Point > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
