Hi Matt,
Let me re-phrase my questions:
1. If there is no TSi and TSr payload in IKE_AUTH exchange, whether we go
ahead and process IKE_AUTH payloads or not ?
2. Appendix C: IKE_AUTH: Error in CHILD SA creation. It will come into
picture if we process the packet.
If we go ahead and process the
On 4/21/2009 5:23 PM, Tero Kivinen wrote:
I still do not think making the 1 RT protocol to 2 RT protocol in that
case would really cause any noticeable effect to the actual handover.
Hi Tero,
How do you know this? I ask because, I would like to use those
arguments to tell people who are
Hello Raj,
According to Appendix C, for IKE_AUTH:
error in Child SA <-- IDr, [CERT+],
creationAUTH,
N(error),
[V+]
So sending an authenticated and encrypted INVALID_SYNTAX notification over
the IKE_SA that has ju
Hi Matt,
There is possibility of just IKEv2 SA gets established during IKE_AUTH and
IPsec SA getting established via CREATE_CHILD_SA.
The question is what behavior RFC mandate ? What you think ?
Thanks for your reply.
Regards,
Raj
On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo wrote:
>
In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit them
from an authentication exchange message, as there would be no way for the SA
to know what traffic should be forwarded through the SA.
It seems that the correct error message would be INVALID_SYNTAX. This would
require the me
Hi Group,
What is the expected behavior if as a responder we do not receive TSi and
TSr in IKE_AUTH exchange ?
Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out TSi and
TSr ?
Or we should reject the packet ?
If we reject the packet during packet validation with doing ID and AUTH
>
> From the ipsecme charter:
>
> Failover from one gateway to another, mechanisms for detecting
> when a session should be resumed, and specifying communication
> mechanisms between gateways are beyond the scope of this work
> item.
>
> Thus failover from one gateway to an
Since its first draft, the IKEv2 bis document has had flags for where new text
came from RFC 4718, such as "{{ Clarif-6.1 }}" and "{{ Clarif-4.2}}". Using a
related notation, we have also marked where text that originally existed in the
top-heavy listing of notifications has been moved into the
Yaron Sheffer writes:
> However, given that normal NAT detection happens during IKE_SA_INIT, can you
> clarify why this would work better if we had a 2 RT protocol?
I think this should explain it:
> > exchange too. Allowing IP-addresses change means that the network
> > where the packets can come
Kalyani Garigipati (kagarigi) writes:
> Please validate if the following is true.
>
> Apart form Notify, DELETE, Vendor ID, CERT, CERTREQ, PROPOSAL, TRANFORM,
> TSi and TSr all other payloads like SA1, SA2, IDi, IDr, KE, NONCE,
> DELETE, AUTH, CONFIG, ENCRYPT should not be sent as multiple payload
Hi Tero,
I have opened Issue #101 for your comments (being too lazy to process them
into multiple issues), and we will process them in batch mode.
Thanks,
Yaron
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Tero Kivinen
> Sent:
During the other discussion I read the
draft-ietf-ipsecme-ikev2-resumption-02 through and here are some more
generic comments to it:
---
In Section 3 we present 2 use cases, and then after figure 1 start
talking about "In this scenario..." and I think that refers to first
use scenario described i
Hi Tero,
To answer the last part of your mail, we always intended address change (and
presumably, NAT detection status change) to be supported. This should be
clarified in the document, and I have opened Issue #100 for this.
However, given that normal NAT detection happens during IKE_SA_INIT, can
Hi,
Please validate if the following is true.
Apart form Notify, DELETE, Vendor ID, CERT, CERTREQ, PROPOSAL, TRANFORM,
TSi and TSr all other payloads like SA1, SA2, IDi, IDr, KE, NONCE,
DELETE, AUTH, CONFIG, ENCRYPT should not be sent as multiple payloads.
Like if we get packet as HDR, SA1, SA1
Narayanan, Vidya writes:
> Hi Yaron,
> We are going back to revisiting consensus here and re-explaining the
> use cases and I'd certainly like to keep this to as minimum a
> revisit as possible. The use cases go back to what has been
> documented in the problem statement we published a while back
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
Paul Hoffman writes:
> At 3:55 PM +0300 4/3/09, Tero Kivinen wrote:
> >Btw, is there any reason why [V+] is not listed in the IKE_AUTH
> >excghange with EAP in the intermediate EAP messages and final AUTH
> >request from the initiator?
>
> We could add it, but I think that would surprise some impl
17 matches
Mail list logo
