Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
Hi Vijay, "It SHOULD delete ... using the same procedure as Sec. 6"? Clarity of prose at the expense of the beauty :-( Thanks, Yaron > -Original Message- > From: Vijay Devarapalli [mailto:vi...@wichorus.com] > Sent: Tuesday, May 05, 2009 9:00 > To: Yaron Sheffer; pasi.ero...@nokia.com; ipsec@ietf.org > Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 > > Hi Yaron, > > > > The current text assumes that the IKE SA is created and needs to be > > > deleted. > > > I don't think we need to show the INFORMATIONAL exchange. > > We are not > > > modifying anything in the delete procedure. We currently have the > > > following text > > > > > >When the client > > >receives the IKE_AUTH response with the REDIRECT > > payload, it SHOULD > > >delete the existing IKEv2 security association with the gateway. > > > > > > Isn't this sufficient? > > > > > No, it's not sufficient. Unfortunately the word "delete" is > > ambiguous, and people can understand it either as "silently > > delete" or "delete and inform the peer". So I'd rather have > > "it SHOULD delete ... using an Informational exchange." > > The previous section already says this. > >Once the client sends an acknowledgement to the gateway, it SHOULD >delete the existing security associations with the old gateway by >sending an Informational message with a DELETE payload. The gateway >MAY also decide to delete the security associations without any >signaling from the client, again by sending an Informational message >with a DELETE payload. > > I guess you want this text repeated in section 6 too (?) > > Vijay > > Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
Hi Yaron, > > The current text assumes that the IKE SA is created and needs to be > > deleted. > > I don't think we need to show the INFORMATIONAL exchange. > We are not > > modifying anything in the delete procedure. We currently have the > > following text > > > >When the client > >receives the IKE_AUTH response with the REDIRECT > payload, it SHOULD > >delete the existing IKEv2 security association with the gateway. > > > > Isn't this sufficient? > > > No, it's not sufficient. Unfortunately the word "delete" is > ambiguous, and people can understand it either as "silently > delete" or "delete and inform the peer". So I'd rather have > "it SHOULD delete ... using an Informational exchange." The previous section already says this. Once the client sends an acknowledgement to the gateway, it SHOULD delete the existing security associations with the old gateway by sending an Informational message with a DELETE payload. The gateway MAY also decide to delete the security associations without any signaling from the client, again by sending an Informational message with a DELETE payload. I guess you want this text repeated in section 6 too (?) Vijay ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
> > > 3) Section 6, 1st paragraph: I think this text needs to be clearer > > about whether an IKE_SA is created or not (current the SHOULDs > > etc. make this somewhat unclear). IMHO if the client will always just > > close the IKE_SA, it doesn't make much sense to create it in the first > > place? But it looks like the intent of the current text might have > > been that the IKE_SA *is* created... If that's the case, then the > > message diagram below this paragraph should also show the > > INFORMATIONAL exchange with Delete payload. > > The current text assumes that the IKE SA is created and needs to be > deleted. > I don't think we need to show the INFORMATIONAL exchange. We are not > modifying anything in the delete procedure. We currently have the > following > text > >When the client >receives the IKE_AUTH response with the REDIRECT payload, it SHOULD >delete the existing IKEv2 security association with the gateway. > > Isn't this sufficient? > No, it's not sufficient. Unfortunately the word "delete" is ambiguous, and people can understand it either as "silently delete" or "delete and inform the peer". So I'd rather have "it SHOULD delete ... using an Informational exchange." Thanks, Yaron smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
h the REDIRECT payload, it SHOULD delete the existing IKEv2 security association with the gateway. Isn't this sufficient? > 4) Section 6, last paragraph: > >> In such cases, the gateway should send the REDIRECT notification >> payload in the final IKE_AUTH response message that carries the AUTH >> payload and the traffic selectors. The gateway MUST NOT send and >> the client MUST NOT accept a redirect in an earlier IKE_AUTH >> message. > > This is a bit confusing, since the first sentence says "should", and > in this particular case, the final IKE_AUTH response does not > actually have the traffic selectors! Also, if the intent was to allow > redirect in the 1st IKE_AUTH response, this text doesn't do it. > Perhaps something like this? > >In such cases, the gateway can include the REDIRECT notification >either in the first IKE_AUTH response, or the last IKE_AUTH >response. The gateway MUST NOT send, and the client MUST NOT >accept, the REDIRECT notification in any other IKE_AUTH response. The gateway can always include the REDRIECT notification in the first IKE_AUTH response. The text that you quoted follows the text that says the redirect decision may be done based on the interaction with the AAA server or an external authentication server. But Yoav also had a comment on the same paragraph. This means it is not clear. So I am fine with adopting your text above. > 5) Section 9, last paragraph, is a bit confusing (even if the redirect > message was always authenticated, we still wouldn't want to modify the > PAD based on it), and in the wrong place (it's important part of the > protocol, not just a security consideration). The proposed text for > Section 3 included the essential parts, I think. Ok, removed the last paragraph in section 9. Vijay > > Best regards, > Pasi > >> -Original Message- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of ext Yaron Sheffer >> Sent: 16 April, 2009 10:38 >> To: IPsecme WG >> Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 >> >> This is a 2 week working group last call for >> draft-ietf-ipsecme-ikev2-redirect-08. The target status for this >> document is >> Proposed Standard. This is the document's second last call, following >> comments by a number of people and several document revisions. >> >> Please send your comments to the ipsec list by April 30, 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-08. >> >> Thanks, >> Yaron > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
n authenticated; see Section 6), the MN MAY pass the new address to Mobile IPv6 and treat it in similar fashion as information from the Home Agent Switch Message [RFC5142]. Gateway-initiated REDIRECT notifications exchanged in INFORMATIONAL exchanges (see Section 5) MUST NOT result in updating any Mobile IPv6 state. In such cases, the Home Agent Switch Message specified in [RFC5142] are used instead. (I haven't fully thought through all the details, so comments are welcome...) And the security considerations text needs something, too. 3) Section 6, 1st paragraph: I think this text needs to be clearer about whether an IKE_SA is created or not (current the SHOULDs etc. make this somewhat unclear). IMHO if the client will always just close the IKE_SA, it doesn't make much sense to create it in the first place? But it looks like the intent of the current text might have been that the IKE_SA *is* created... If that's the case, then the message diagram below this paragraph should also show the INFORMATIONAL exchange with Delete payload. 4) Section 6, last paragraph: > In such cases, the gateway should send the REDIRECT notification > payload in the final IKE_AUTH response message that carries the AUTH > payload and the traffic selectors. The gateway MUST NOT send and > the client MUST NOT accept a redirect in an earlier IKE_AUTH > message. This is a bit confusing, since the first sentence says "should", and in this particular case, the final IKE_AUTH response does not actually have the traffic selectors! Also, if the intent was to allow redirect in the 1st IKE_AUTH response, this text doesn't do it. Perhaps something like this? In such cases, the gateway can include the REDIRECT notification either in the first IKE_AUTH response, or the last IKE_AUTH response. The gateway MUST NOT send, and the client MUST NOT accept, the REDIRECT notification in any other IKE_AUTH response. 5) Section 9, last paragraph, is a bit confusing (even if the redirect message was always authenticated, we still wouldn't want to modify the PAD based on it), and in the wrong place (it's important part of the protocol, not just a security consideration). The proposed text for Section 3 included the essential parts, I think. Best regards, Pasi > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of ext Yaron Sheffer > Sent: 16 April, 2009 10:38 > To: IPsecme WG > Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08 > > This is a 2 week working group last call for > draft-ietf-ipsecme-ikev2-redirect-08. The target status for this > document is > Proposed Standard. This is the document's second last call, following > comments by a number of people and several document revisions. > > Please send your comments to the ipsec list by April 30, 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-08. > > Thanks, > Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
So are we working with the assumption that the gateway (or the AAA server) can
always authenticate any user that connects?
> -Original Message-
> From: Yaron Sheffer
> Sent: Monday, April 20, 2009 10:43 AM
> To: Yoav Nir; Vijay Devarapalli
> Cc: IPsecme WG
> Subject: RE: [IPsec] WG Last Call:
> draft-ietf-ipsecme-ikev2-redirect-08
>
> Below.
>
> > -Original Message-
> > From: Yoav Nir
> > Sent: Monday, April 20, 2009 10:30
> > To: Vijay Devarapalli
> > Cc: Yaron Sheffer; IPsecme WG
> > Subject: RE: [IPsec] WG Last Call:
> > draft-ietf-ipsecme-ikev2-redirect-08
> >
> > Hi
> >
> > Come to think of it, I'm wondering about something else.
> >
> > Let's suppose that the gateway cannot tell where the user
> should connect.
> > The EAP exchange with the AAA server begins. The AAA server
> realizes
> > that the user name ("jdoe") is not in its database, and the user
> > should be redirected to gateway B.
> >
> > What now? Does it complete the exchange successfully, and
> redirect?
> > Or does it fail the exchange and redirect?
> >
> > I think the obvious answer is to fail the exchange and redirect. I
> > think we should mandate that even with EAP failure, the
> client should
> > honor the REDIRECT.
> >
> > If the gateway authentication fails (the AUTH payload in the first
> > IKE_AUTH response fails to authenticate) then I'm not sure what the
> > right action is. REDIRECT is accepted in an
> unauthenticated INITIAL exchange.
> > Why not, then, in a failed authentication IKE_AUTH exchange?
> >
> [YS] No, failing authentication is different from being
> unauthenticated. The client may have a policy that says that
> it's willing to be redirected at IKE_SA_INIT. But if it
> receives an AUTH value that is explicitly untrusted (say,
> with a revoked certificate), I think it should not act on it.
> Even though a malicious gateway could have responded in the
> first exchange etc.
> etc.
>
> Also note that it may be hard to untangle client
> authentication from gateway authentication, e.g. when using
> symmetric password authentication such as EAP-EKE
> .
Email secured by Check Point
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
Below.
> -Original Message-
> From: Yoav Nir
> Sent: Monday, April 20, 2009 10:30
> To: Vijay Devarapalli
> Cc: Yaron Sheffer; IPsecme WG
> Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
>
> Hi
>
> Come to think of it, I'm wondering about something else.
>
> Let's suppose that the gateway cannot tell where the user should connect.
> The EAP exchange with the AAA server begins. The AAA server realizes that
> the user name ("jdoe") is not in its database, and the user should be
> redirected to gateway B.
>
> What now? Does it complete the exchange successfully, and redirect? Or
> does it fail the exchange and redirect?
>
> I think the obvious answer is to fail the exchange and redirect. I think
> we should mandate that even with EAP failure, the client should honor the
> REDIRECT.
>
> If the gateway authentication fails (the AUTH payload in the first
> IKE_AUTH response fails to authenticate) then I'm not sure what the right
> action is. REDIRECT is accepted in an unauthenticated INITIAL exchange.
> Why not, then, in a failed authentication IKE_AUTH exchange?
>
[YS] No, failing authentication is different from being unauthenticated. The
client may have a policy that says that it's willing to be redirected at
IKE_SA_INIT. But if it receives an AUTH value that is explicitly untrusted
(say, with a revoked certificate), I think it should not act on it. Even
though a malicious gateway could have responded in the first exchange etc.
etc.
Also note that it may be hard to untangle client authentication from gateway
authentication, e.g. when using symmetric password authentication such as
EAP-EKE .
> Vijay Devarapalli wrote:
>
> > Hi,
> >
> > On 4/18/09 11:16 AM, "Yoav Nir" wrote:
> >
> > > Vijay Devarapalli wrote:
> > >>
> > >> Hello,
> > >>
> > >> Yoav Nir wrote:
> > >>> I see that in section 6 the following:
> > >>>
> > >>>In such cases, the gateway should send the REDIRECT
> > notification
> > >>>payload in the final IKE_AUTH response message that
> > carries the AUTH
> > >>>payload and the traffic selectors. The gateway MUST
> > NOT send and the
> > >>>client MUST NOT accept a redirect in an earlier
> > IKE_AUTH message.
> > >>>
> > >>> I like that, and that was my position earlier, but wasn't the
> > >>> conclusion at San Francisco that the REDIRECT could come
> > in either
> > >>> the first AUTH response (where we know the ID the client
> > is using,
> > >>> temporary or not)
> > >>> *OR* in the last response?
> > >>
> > >> The text you quote above refers to the case when the
> > gateway decides
> > >> to redirect based on the EAP exchange or a as a result of
> > interaction
> > >> with the AAA server or some external entity (when multiple auth is
> > >> used). The redirect is done in the final IKE_AUTH message.
> > >>
> > >>> When did we decide to not allow it in the first resopnse?
> > >>
> > >> We allow it. The first paragraph in section 6 and the message
> > >> exchange just below it show this.
> > >>
> > >> Vijay
> > >
> > > The first paragraph refers to the non-EAP case. The
> > paragraph I quoted
> > > is the one that refers to the EAP case, and this is the
> > case where it
> > > makes sense to allow the REDIRECT both in the first and
> > last IKE_AUTH
> > > responses.
> > >
> > > The case for the last response is the one that you made: The AAA
> > > server may tell the gateway to send the user to another gateway.
> > >
> > > The case for the first response is a little different. The
> > content of
> > > the IDi payload tells the gateway to what domain the user
> > belongs. "Domain"
> > > could map to a specific AAA server, and/or to a specific gateway.
> > >
> > > Suppose a user connects to gateway-A with the IDi payload
> > containing
> > > "j...@companyb.com". This is enough to tell the gateway
> > that the user
> > > should use gateway-B instead - policy says that all
> > companyB employees
> > > connect to the gateway-B. Or maybe the user is
> > "j...@company.it" and
> > > all such users should connect to the gateway
> > > in Italy. In both cases there is no point in
> > authenticating to the local
> > > AAA server. The gateway knows immediately to send the user to the
> > > appropriate gateway.
> > >
> > > That is why I think (and I believe that was the conclusion
> > in SF) that
> > > the REDIRECT may come in both the first and last responses.
> >
> > Ok, got it. Redirect in the first IKE_AUTH response is always
> > allowed, even if there is an EAP exchange. I will clarify it
> > in the next revision.
> >
> > Vijay
> >
> > >
> > > Yoav
smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
Hi
Come to think of it, I'm wondering about something else.
Let's suppose that the gateway cannot tell where the user should connect. The
EAP exchange with the AAA server begins. The AAA server realizes that the user
name ("jdoe") is not in its database, and the user should be redirected to
gateway B.
What now? Does it complete the exchange successfully, and redirect? Or does
it fail the exchange and redirect?
I think the obvious answer is to fail the exchange and redirect. I think we
should mandate that even with EAP failure, the client should honor the REDIRECT.
If the gateway authentication fails (the AUTH payload in the first IKE_AUTH
response fails to authenticate) then I'm not sure what the right action is.
REDIRECT is accepted in an unauthenticated INITIAL exchange. Why not, then, in
a failed authentication IKE_AUTH exchange?
Vijay Devarapalli wrote:
> Hi,
>
> On 4/18/09 11:16 AM, "Yoav Nir" wrote:
>
> > Vijay Devarapalli wrote:
> >>
> >> Hello,
> >>
> >> Yoav Nir wrote:
> >>> I see that in section 6 the following:
> >>>
> >>>In such cases, the gateway should send the REDIRECT
> notification
> >>>payload in the final IKE_AUTH response message that
> carries the AUTH
> >>>payload and the traffic selectors. The gateway MUST
> NOT send and the
> >>>client MUST NOT accept a redirect in an earlier
> IKE_AUTH message.
> >>>
> >>> I like that, and that was my position earlier, but wasn't the
> >>> conclusion at San Francisco that the REDIRECT could come
> in either
> >>> the first AUTH response (where we know the ID the client
> is using,
> >>> temporary or not)
> >>> *OR* in the last response?
> >>
> >> The text you quote above refers to the case when the
> gateway decides
> >> to redirect based on the EAP exchange or a as a result of
> interaction
> >> with the AAA server or some external entity (when multiple auth is
> >> used). The redirect is done in the final IKE_AUTH message.
> >>
> >>> When did we decide to not allow it in the first resopnse?
> >>
> >> We allow it. The first paragraph in section 6 and the message
> >> exchange just below it show this.
> >>
> >> Vijay
> >
> > The first paragraph refers to the non-EAP case. The
> paragraph I quoted
> > is the one that refers to the EAP case, and this is the
> case where it
> > makes sense to allow the REDIRECT both in the first and
> last IKE_AUTH
> > responses.
> >
> > The case for the last response is the one that you made: The AAA
> > server may tell the gateway to send the user to another gateway.
> >
> > The case for the first response is a little different. The
> content of
> > the IDi payload tells the gateway to what domain the user
> belongs. "Domain"
> > could map to a specific AAA server, and/or to a specific gateway.
> >
> > Suppose a user connects to gateway-A with the IDi payload
> containing
> > "j...@companyb.com". This is enough to tell the gateway
> that the user
> > should use gateway-B instead - policy says that all
> companyB employees
> > connect to the gateway-B. Or maybe the user is
> "j...@company.it" and
> > all such users should connect to the gateway
> > in Italy. In both cases there is no point in
> authenticating to the local
> > AAA server. The gateway knows immediately to send the user to the
> > appropriate gateway.
> >
> > That is why I think (and I believe that was the conclusion
> in SF) that
> > the REDIRECT may come in both the first and last responses.
>
> Ok, got it. Redirect in the first IKE_AUTH response is always
> allowed, even if there is an EAP exchange. I will clarify it
> in the next revision.
>
> Vijay
>
> >
> > Yoav
Email secured by Check Point
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
Hi, On 4/18/09 11:16 AM, "Yoav Nir" wrote: > Vijay Devarapalli wrote: >> >> Hello, >> >> Yoav Nir wrote: >>> I see that in section 6 the following: >>> >>>In such cases, the gateway should send the REDIRECT notification >>>payload in the final IKE_AUTH response message that carries the AUTH >>>payload and the traffic selectors. The gateway MUST NOT send and the >>>client MUST NOT accept a redirect in an earlier IKE_AUTH message. >>> >>> I like that, and that was my position earlier, but wasn't the conclusion at >>> San Francisco that the REDIRECT could come in either the first AUTH >>> response (where we know the ID the client is using, temporary or not) >>> *OR* in the last response? >> >> The text you quote above refers to the case when the gateway decides to >> redirect based on the EAP exchange or a as a result of interaction with >> the AAA server or some external entity (when multiple auth is used). The >> redirect is done in the final IKE_AUTH message. >> >>> When did we decide to not allow it in the first resopnse? >> >> We allow it. The first paragraph in section 6 and the message exchange >> just below it show this. >> >> Vijay > > The first paragraph refers to the non-EAP case. The paragraph I quoted > is the one that refers to the EAP case, and this is the case where it makes > sense to allow the REDIRECT both in the first and last IKE_AUTH > responses. > > The case for the last response is the one that you made: The AAA server > may tell the gateway to send the user to another gateway. > > The case for the first response is a little different. The content of the IDi > payload tells the gateway to what domain the user belongs. "Domain" > could map to a specific AAA server, and/or to a specific gateway. > > Suppose a user connects to gateway-A with the IDi payload containing > "j...@companyb.com". This is enough to tell the gateway that the > user should use gateway-B instead - policy says that all companyB > employees connect to the gateway-B. Or maybe the user is > "j...@company.it" and all such users should connect to the gateway > in Italy. In both cases there is no point in authenticating to the local > AAA server. The gateway knows immediately to send the user to the > appropriate gateway. > > That is why I think (and I believe that was the conclusion in SF) that > the REDIRECT may come in both the first and last responses. Ok, got it. Redirect in the first IKE_AUTH response is always allowed, even if there is an EAP exchange. I will clarify it in the next revision. Vijay > > Yoav > > Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
Vijay Devarapalli wrote: > > Hello, > > Yoav Nir wrote: > > I see that in section 6 the following: > > > >In such cases, the gateway should send the REDIRECT notification > >payload in the final IKE_AUTH response message that carries the AUTH > >payload and the traffic selectors. The gateway MUST NOT send and the > >client MUST NOT accept a redirect in an earlier IKE_AUTH message. > > > > I like that, and that was my position earlier, but wasn't the conclusion at > > San Francisco that the REDIRECT could come in either the first AUTH > > response (where we know the ID the client is using, temporary or not) > > *OR* in the last response? > > The text you quote above refers to the case when the gateway decides to > redirect based on the EAP exchange or a as a result of interaction with > the AAA server or some external entity (when multiple auth is used). The > redirect is done in the final IKE_AUTH message. > > > When did we decide to not allow it in the first resopnse? > > We allow it. The first paragraph in section 6 and the message exchange > just below it show this. > > Vijay The first paragraph refers to the non-EAP case. The paragraph I quoted is the one that refers to the EAP case, and this is the case where it makes sense to allow the REDIRECT both in the first and last IKE_AUTH responses. The case for the last response is the one that you made: The AAA server may tell the gateway to send the user to another gateway. The case for the first response is a little different. The content of the IDi payload tells the gateway to what domain the user belongs. "Domain" could map to a specific AAA server, and/or to a specific gateway. Suppose a user connects to gateway-A with the IDi payload containing "j...@companyb.com". This is enough to tell the gateway that the user should use gateway-B instead - policy says that all companyB employees connect to the gateway-B. Or maybe the user is "j...@company.it" and all such users should connect to the gateway in Italy. In both cases there is no point in authenticating to the local AAA server. The gateway knows immediately to send the user to the appropriate gateway. That is why I think (and I believe that was the conclusion in SF) that the REDIRECT may come in both the first and last responses. Yoav Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
Hello, Yoav Nir wrote: I see that in section 6 the following: In such cases, the gateway should send the REDIRECT notification payload in the final IKE_AUTH response message that carries the AUTH payload and the traffic selectors. The gateway MUST NOT send and the client MUST NOT accept a redirect in an earlier IKE_AUTH message. I like that, and that was my position earlier, but wasn't the conclusion at San Francisco that the REDIRECT could come in either the first AUTH response (where we know the ID the client is using, temporary or not) *OR* in the last response? The text you quote above refers to the case when the gateway decides to redirect based on the EAP exchange or a as a result of interaction with the AAA server or some external entity (when multiple auth is used). The redirect is done in the final IKE_AUTH message. When did we decide to not allow it in the first resopnse? We allow it. The first paragraph in section 6 and the message exchange just below it show this. Vijay Other than that, I think the document is fine and ready for publication. Yaron Sheffer wrote: This is a 2 week working group last call for draft-ietf-ipsecme-ikev2-redirect-08. The target status for this document is Proposed Standard. This is the document's second last call, following comments by a number of people and several document revisions. Please send your comments to the ipsec list by April 30, 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-08. Thanks, Yaron Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
I see that in section 6 the following: In such cases, the gateway should send the REDIRECT notification payload in the final IKE_AUTH response message that carries the AUTH payload and the traffic selectors. The gateway MUST NOT send and the client MUST NOT accept a redirect in an earlier IKE_AUTH message. I like that, and that was my position earlier, but wasn't the conclusion at San Francisco that the REDIRECT could come in either the first AUTH response (where we know the ID the client is using, temporary or not) *OR* in the last response? When did we decide to not allow it in the first resopnse? Other than that, I think the document is fine and ready for publication. Yaron Sheffer wrote: > This is a 2 week working group last call for > draft-ietf-ipsecme-ikev2-redirect-08. The target status for > this document is Proposed Standard. This is the document's > second last call, following comments by a number of people > and several document revisions. > > Please send your comments to the ipsec list by April 30, > 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-08. > > Thanks, > Yaron Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
This is a 2 week working group last call for draft-ietf-ipsecme-ikev2-redirect-08. The target status for this document is Proposed Standard. This is the document's second last call, following comments by a number of people and several document revisions. Please send your comments to the ipsec list by April 30, 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-08. Thanks, Yaron smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
