Re: [IPsec] Query regarding IKE_SA_AUTH response

[Raj Singh]

Hi Prashant,

As per RFC 5996, Initiator sending AUTHENTICATION_FAILED would be sufficient
in case of peer's authentication failure:

Sec. 2.21.2 Error Handling in IKE_AUTH

...

If the error occurs on the initiator, the notification MAY be
returned in a separate INFORMATIONAL exchange, usually with no other
payloads.  This is an exception for the general rule of not starting
new exchanges based on errors in responses.

...

In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately
following it (in case an error happened when processing a response to
IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and
AUTHENTICATION_FAILED notifications are the only ones to cause the
IKE SA to be deleted or not created, without a Delete payload.

...


Regards,
Raj



On Wed, Apr 27, 2011 at 7:09 PM, Prashant Batra (prbatra)  wrote:

>  Thanks Scott,
>
>
>
>  I also prefer sending the AUTHENTICATION FAILED and a DELETE PAYLOAD, so
> as to ensure that the peer deletes the ipsec tunnel from the SADB (as it
> would have already added the tunnel in SADB, after sending the
> AUTH_RESPONSE).
>
> But, to second you, most implementations would delete the same on receiving
> AUTHENTICATION FAILED alone.
>
>
>
> Regards,
>
> Prashant
>
>
>
>
>
> *From:* Scott C Moonen [mailto:smoo...@us.ibm.com]
> *Sent:* Wednesday, April 27, 2011 5:54 PM
> *To:* Prashant Batra (prbatra)
> *Cc:* ipsec@ietf.org; ipsec-boun...@ietf.org
> *Subject:* Re: [IPsec] Query regarding IKE_SA_AUTH response
>
>
>
> Hi Prashant.
>
> > 1) If in IKE_AUTH request message initiator sends a ID_R
> > payload(optional) specifying a particular peer identity, and the
> > responder
> > sends some different identity in the ID_R payload, what should be the
> > behavior? Should we send a AUTHENTICATION failure message,
> > or except this new identity of the peer and mark the SA established, if
> > the other things are fine.
>
> This is an implementation decision. In general, you should not
> automatically reject the negotiation because the optional IDr is intended
> only as a hint. Instead, you should (1) check whether your peer
> authorization database (PAD) allows you to converse with the new identity at
> the given IP address and to protect the given traffic, and (2) be sure to
> verify that any earlier decisions, such as the use of a particular
> pre-shared key or the choice of IKE SA cryptographic algorithms, are still
> correct given that you are talking to a different identity than you first
> suspected.
>
> > 2) If we were to send a AUTHENTICATION failure, then this should be sent
> > as a INFORMATIONAL exchange message (as the message received
> > is a response and not request). What should be the message Id used?
>
> Yes, if you were to determine that the peer identity is not permitted by
> your PAD, then you would initiate a new informational exchange on the IKE
> SA. Since the IKE_AUTH exchange has a message id of 1, this exchange would
> have a message id of 2. My own preference would be to send both an
> AUTHENTICATION_FAILED payload and a delete payload for the IKE SA, for
> maximum clarity. But I think that sending only AUTHENTICATION_FAILED is
> sufficient and would be the preference of others on this list.
>
>
> Scott Moonen (smoo...@us.ibm.com)
> z/OS Communications Server TCP/IP Development
> http://www.linkedin.com/in/smoonen
>
> [image: Inactive hide details for "Prashant Batra (prbatra)" ---04/27/2011
> 08:06:01 AM---Hi, I have 2 doubts regarding IKEv2,]"Prashant Batra
> (prbatra)" ---04/27/2011 08:06:01 AM---Hi, I have 2 doubts regarding IKEv2,
>
> From: "Prashant Batra (prbatra)" 
> To: 
> Date: 04/27/2011 08:06 AM
> Subject: [IPsec] Query regarding IKE_SA_AUTH response
> Sent by: ipsec-boun...@ietf.org
>  --
>
>
>
>
> Hi,
>
> I have 2 doubts regarding IKEv2,
>
> 1) If in IKE_AUTH request message initiator sends a ID_R
> payload(optional) specifying a particular peer identity, and the
> responder
> sends some different identity in the ID_R payload, what should be the
> behavior? Should we send a AUTHENTICATION failure message,
> or except this new identity of the peer and mark the SA established, if
> the other things are fine.
>
> 2) If we were to send a AUTHENTICATION failure, then this should be sent
> as a INFORMATIONAL exchange message (as the message received
> is a response and not request). What should be the message Id used?
>
> Regards,
> Prashant
>
>
>
> ___
> 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
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [IKEv2] IKE_AUTH without TSi, TSr

[raj singh]

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
payload processing, what ERROR should be send ?

Thanks,
Raj
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr

[raj singh]

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 message ID and the checksum to be valid. Note that this has (may
> only) be sent in an encrypted response.
>
> Please correct me if I am wrong.
>
> Regards,
> Matt
>
>
>> 2009/4/22 raj singh 
>>
>>>  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
>>> payload processing, what ERROR should be send ?
>>>
>>> Thanks,
>>> Raj
>>>
>>>
>>> ___
>>> 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] [IKEv2] IKE_AUTH without TSi, TSr

[raj singh]

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 packet, according to appendix C, we
SHOULD/MUST establish the IKE SA ?
Looks like, if we go ahead to process the IKE_AUTH packet with no TSi
and TSr, we can establish the IKEv2 SA.

I request more experts to comment.

Thanks for your reply.

Regards,
Raj

On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini Sarreo wrote:

> 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 just been authenticated seems to be correct.
>
> Regards,
> Matt
>
>
>>
>> 2009/4/22 raj singh 
>>
>>> 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 message ID and the checksum to be valid. Note that this
>>>> has (may only) be sent in an encrypted response.
>>>>
>>>> Please correct me if I am wrong.
>>>>
>>>> Regards,
>>>> Matt
>>>>
>>>>
>>>>> 2009/4/22 raj singh 
>>>>>
>>>>>>  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 payload processing, what ERROR should be send ?
>>>>>>
>>>>>> Thanks,
>>>>>> Raj
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> 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] [IKEv2] IKE_AUTH without TSi, TSr

[raj singh]

Hi Matt/Youv,

Thanks for your reply.
I will conclude as IKE_AUTH exchange MUST have TSi and TSr payload. We MUST
NOT process IKE_AUTH packet without TSi and TSr and we should reply with
INVALID_SYNTAX notification without IDr, AUTH, TSi and TSr payloads.

Regards,
Raj

On Wed, Apr 22, 2009 at 1:11 PM, Yoav Nir  wrote:

>  Hi Raj
>
> Matt is correct. There is no way in IKEv2 to do a phase1-only exchange, and
> then wait for traffic to establish the child SAs.
>
> While we do establish an IKE SA if the piggy-backed child SA failed for
> whatever reason (bad selectors, no proposal chosen), we don't allow for an
> IKE_AUTH exchange that is missing the child payloads.
>
> An IKE_AUTH request without the TSi and TSr payloads is
> considered malformed, and so MUST NOT be processed. Instead, you should
> reply with INVALID_SYNTAX
>
> As to question 2, the text refers to a child SA creation that failed, not
> to one that was never attempted.
>
> Of course it is possible to generate that effect - propose non-existant
> cryptographic algorithms, or IPv7 addresses in the selectors, but that IMO
> is a misuse of the protocol.
>
> Yoav
>
> Raj Singh wrote:
>
> 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 packet, according to appendix C, we
> SHOULD/MUST establish the IKE SA ?
> Looks like, if we go ahead to process the IKE_AUTH packet with no TSi
> and TSr, we can establish the IKEv2 SA.
>
> I request more experts to comment.
>
> Thanks for your reply.
>
> Regards,
> Raj
>
> On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini Sarreo wrote:
>
>>   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 just been authenticated seems to be correct.
>>
>> Regards,
>> Matt
>>
>>
>>>
>>> 2009/4/22 raj singh 
>>>
>>>> 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 message ID and the checksum to be valid. Note that this
>>>>> has (may only) be sent in an encrypted response.
>>>>>
>>>>> Please correct me if I am wrong.
>>>>>
>>>>> Regards,
>>>>> Matt
>>>>>
>>>>>
>>>>>> 2009/4/22 raj singh 
>>>>>>
>>>>>>>  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 payload processing, what ERROR should be send ?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Raj
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> IPsec mailing list
>>>>>>> IPsec@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> Email secured by Check Point
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr

[raj singh]

Hi Matt,

Buy as per Youv, we should not process the request.
Is that means, that we will not process the request but send IDr and AUTH
payloads ?

Thanks,
Raj

On Wed, Apr 22, 2009 at 2:48 PM, Matthew Cini Sarreo wrote:

> Hello Raj,
>
> You still need the IDr and AUTH payloads in the reply. This is needed as
> INVALID_SYNTAX is authenticated and encrypted.
>
>
> Regards,
> Matt
>
> 2009/4/22 raj singh 
>
>> Hi Matt/Youv,
>>
>> Thanks for your reply.
>> I will conclude as IKE_AUTH exchange MUST have TSi and TSr payload. We
>> MUST NOT process IKE_AUTH packet without TSi and TSr and we should reply
>> with INVALID_SYNTAX notification without IDr, AUTH, TSi and TSr payloads.
>>
>> Regards,
>> Raj
>>
>>
>> On Wed, Apr 22, 2009 at 1:11 PM, Yoav Nir  wrote:
>>
>>>  Hi Raj
>>>
>>> Matt is correct. There is no way in IKEv2 to do a phase1-only exchange,
>>> and then wait for traffic to establish the child SAs.
>>>
>>> While we do establish an IKE SA if the piggy-backed child SA failed for
>>> whatever reason (bad selectors, no proposal chosen), we don't allow for an
>>> IKE_AUTH exchange that is missing the child payloads.
>>>
>>> An IKE_AUTH request without the TSi and TSr payloads is
>>> considered malformed, and so MUST NOT be processed. Instead, you should
>>> reply with INVALID_SYNTAX
>>>
>>> As to question 2, the text refers to a child SA creation that failed, not
>>> to one that was never attempted.
>>>
>>> Of course it is possible to generate that effect - propose non-existant
>>> cryptographic algorithms, or IPv7 addresses in the selectors, but that IMO
>>> is a misuse of the protocol.
>>>
>>> Yoav
>>>
>>> Raj Singh wrote:
>>>
>>> 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 packet, according to appendix C, we
>>> SHOULD/MUST establish the IKE SA ?
>>> Looks like, if we go ahead to process the IKE_AUTH packet with no TSi
>>> and TSr, we can establish the IKEv2 SA.
>>>
>>> I request more experts to comment.
>>>
>>> Thanks for your reply.
>>>
>>> Regards,
>>> Raj
>>>
>>> On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini Sarreo 
>>> wrote:
>>>
>>>>   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 just been authenticated seems to be correct.
>>>>
>>>> Regards,
>>>> Matt
>>>>
>>>>
>>>>>
>>>>> 2009/4/22 raj singh 
>>>>>
>>>>>> 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 <
>>>>>> mci...@gmail.com> 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 message ID and the checksum to be valid. Note that 
>>>>>>> this
>>>>>>> has (may only) be sent in an encrypted response.
>>>>>>>
>>>>>>> Please correct me if I am wrong.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Matt
>>>>>>>
>>>>>>>
>>>>>>>> 2009/4/22 raj singh 
>>>>>>>>
>>>>>>>>>  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 payload processing, what ERROR should be send ?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Raj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ___
>>>>>>>>> IPsec mailing list
>>>>>>>>> IPsec@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> Email secured by Check Point
>>>
>>>
>>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr

[raj singh]

Hi Tero,

It make sense.
The same point i want to make, if we as a responder are not going to process
the packet,
there is NO need to add IDr and AUTH with INVALID_SYNTAX during IKE_AUTH.

Regards,
Raj

On Wed, Apr 22, 2009 at 4:43 PM, Tero Kivinen  wrote:

> Matthew Cini Sarreo writes:
> > You still need the IDr and AUTH payloads in the reply. This is needed as
> > INVALID_SYNTAX is authenticated and encrypted.
>
> INVALID_SYNTAX is fatal error meaning that other end didn't follow the
> protocol specification, and the IKE SA is going to be removed anyways,
> and there is not really point of putting AUTH payload there (it can be
> there, but there is no need).
>
> If the other end is not following protocol specification (i.e. is
> non-complient), there is not really point of trying to be nice. This
> is something that cannot be seen by normal customers ever, it should
> only be seen by the implementors when they are testing against broken
> implementations.
>
> So better just send error message back as it is easiest for your
> implementation (i.e. if it is easy to include AUTH etc to the error
> message, then do so, if not, then leave them out).
> --
> kivi...@iki.fi
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [IKEv2] Error in Child SA creation

[raj singh]

Hi Matt,

I agree with Jeff.
Sending INVALID_SYNTAX notify with no payload and immediately delete IKEv2
SA  will be good idea in case of malformed IKE_AUTH  request.
As SA is still unauthenticated, sending DELETE notify will cause another
problems.

Thanks,
Raj

On Thu, Apr 23, 2009 at 2:04 AM, J. Sun  wrote:

> Matt,
>  In respect to a Notify ERROR TYPES & the IKE_AUTH response with IDr,
> [CERT+] & AUTH payload inclusion, NO_PROPOSAL_CHOSEN, SINGLE_PAIR_REQUIRED,
>  TS_UNACCEPTABLE and NO_ADDITIONAL_SAS are Notify ERROR TYPES that would
> generally still include the IDr, [CERT+] & AUTH payload in the response.
>  In respect to the INVALID_SYNTAX & the IKE_AUTH Response, it's really up
> to the implementation to decide what to do next in respect to receiving a
> malformed IKE_AUTH Request.  One option is suggested by Tero - sending an
> IKE_AUTH Response with an INVALID_SYNTAX and no other payloads.  Another
> option is to simply drop the malformed IKE_AUTH Request and not even send a
> reply.  The point is, there's not much you can really do when a device sends
> you a malformed request/response message - it's not like it's gonna figure
> out what's wrong and fix it.  Whichever option that you go with, you'll have
> to eventually locally delete the unauthenticated IKE_SA - I would not
> continue operating as if the IKE_SA is authenticated by initializing a
> INFORMATIONAL Request with Delete Payloads.  RFC 4306 does not define what
> to do in such cases, and essentially leaves it up to implementations to
> decide on how to handle it - in other words, there isn't a specified way to
> handle every oddball case out there.
>
> - Jeff Sun
>
> Matthew Cini Sarreo wrote:
>
>> Hello all,
>>
>> As IKEv2bis-02 defines in Appendix C, the proper way to notify a requester
>> that there was an error in creating a Child SA using the IKE_AUTH exchange
>> is:
>>
>> error in Child SA  <--  IDr, [CERT+],
>> creationAUTH,
>>   N(error),
>>   [V+]
>>
>> A point came up about this in a previous thread today (IKE_AUTH without
>> TSi, TSr), where an initator would send IKE_AUTH without TSi, TSr. It seemed
>> that a general agreement was to send an INVALID_SYNTAX message without the
>> IDr and AUTH payloads. As it was put:
>>
>> >INVALID_SYNTAX is fatal error meaning that other end didn't follow the
>> >protocol specification, and the IKE SA is going to be removed anyways,
>> >and there is not really point of putting AUTH payload there (it can be
>> > there, but there is no need).
>>
>> > If the other end is not following protocol specification (i.e. is
>> > non-complient), there is not really point of trying to be nice. This
>> > is something that cannot be seen by normal customers ever, it should
>> > only be seen by the implementors when they are testing against broken
>> > implementations.
>>
>> >So better just send error message back as it is easiest for your
>> > implementation (i.e. if it is easy to include AUTH etc to the error
>> > message, then do so, if not, then leave them out).
>>
>> The above seems reasonable to me.
>>
>> What would be the reasoning for adding IDr, [CERT+], AUTH in this
>> scenario? Would it be possible/acceptable to some better text covering
>> INVALID_SYNTAX? Maybe it would specify that when INVALID_SYNTAX would be
>> sent, no other payloads are needed, and what would happen to the SA. Would
>> the SA be interrupted (removed from memory instantly without any
>> confirmation by the party sending the notification), an Informational
>> exchange to delete the SA be initiated or would the party sending
>> INVALID_SYNTAX allow the other endpoint to take some action when receiving
>> this error (maybe the initiator would give up and start an Informational
>> Exchange to delete the SA)?
>>
>> Regards,
>> Matt
>> 
>>
>> ___
>> 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
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr

[raj singh]

Hi Yoav,

If check for mandatory payloads per exchange type is MUST, if it fails we
MUST return INVALID_SYNTAX, why we are not saying it explicitly in the draft
? Putting it clearly in the draft make more sense and avoids many
confusions.

Thanks,
Raj


On Wed, May 6, 2009 at 7:24 PM, Yoav Nir  wrote:

> Hi Michael
>
> > Let me suggest a situation where perhaps I would like to
> > bring up an IKE_SA and not a CHILD_SA: it might be for just
> > sending initial contact, and perhaps even a DELETE.
> >
> > I sometimes move quickly from being "outside" my IPsec
> > gateway/firewall (such as being on wireless), to being wired
> > behind the gateway, where I do not need IPsec.  The DPD
> > doesn't kick off fast enough, and my traffic goes to where I
> > am no longer.  It would be nice to bring up the IKE_SA (or...
> > haha, resume it), just so that I can send a delete and/or
> > initial_contact.
>
> A far more common situation is when I'm "outside", not moving anywhere, and
> I want to connect.  I haven't even opened my mail client yet, or launched
> the browser (because those thing hate it when the VPN client changes routing
> to addresses they are trying to reach).
>
> The reason I want to connect before everything else, is that connecting
> involves some effort (typing the PKCS#12 password, entering a username and
> password, copying the OTP from the cellphone to the computer...). I want to
> get this over with, but there's still no packet to derive selectors from.
>
> With IKEv1 we had the separate Main Mode and then Quick Mode. Now we can't
> do Main Mode without attempting Quick Mode.
>
> > Seems like to do this, once needs to include a
> > known-to-be-unacceptable CHILD_SA proposal.
>
> Actually it doesn't have to be acceptable, as the IKE_AUTH will succeed
> even if the piggy-backed CHILD_SA fails.
>
> Now I would never suggest that anyone use a traffic selectors type from the
> private range (241-255) which is almost guaranteed to fail...
>
> Yoav
> 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] [IKEv2] IKE_AUTH without TSi, TSr

[raj singh]

Hi Team,

One more question.
The INVALID_SYNTAX notify in response to missing payload in IKE_AUTH should
be send encrypted using DH keys or unencrypted ?

Thanks,
raj

On Fri, May 15, 2009 at 10:12 AM, raj singh  wrote:

> Hi Yoav,
>
> If check for mandatory payloads per exchange type is MUST, if it fails we
> MUST return INVALID_SYNTAX, why we are not saying it explicitly in the draft
> ? Putting it clearly in the draft make more sense and avoids many
> confusions.
>
> Thanks,
> Raj
>
>
>
> On Wed, May 6, 2009 at 7:24 PM, Yoav Nir  wrote:
>
>> Hi Michael
>>
>> > Let me suggest a situation where perhaps I would like to
>> > bring up an IKE_SA and not a CHILD_SA: it might be for just
>> > sending initial contact, and perhaps even a DELETE.
>> >
>> > I sometimes move quickly from being "outside" my IPsec
>> > gateway/firewall (such as being on wireless), to being wired
>> > behind the gateway, where I do not need IPsec.  The DPD
>> > doesn't kick off fast enough, and my traffic goes to where I
>> > am no longer.  It would be nice to bring up the IKE_SA (or...
>> > haha, resume it), just so that I can send a delete and/or
>> > initial_contact.
>>
>> A far more common situation is when I'm "outside", not moving anywhere,
>> and I want to connect.  I haven't even opened my mail client yet, or
>> launched the browser (because those thing hate it when the VPN client
>> changes routing to addresses they are trying to reach).
>>
>> The reason I want to connect before everything else, is that connecting
>> involves some effort (typing the PKCS#12 password, entering a username and
>> password, copying the OTP from the cellphone to the computer...). I want to
>> get this over with, but there's still no packet to derive selectors from.
>>
>> With IKEv1 we had the separate Main Mode and then Quick Mode. Now we can't
>> do Main Mode without attempting Quick Mode.
>>
>> > Seems like to do this, once needs to include a
>> > known-to-be-unacceptable CHILD_SA proposal.
>>
>> Actually it doesn't have to be acceptable, as the IKE_AUTH will succeed
>> even if the piggy-backed CHILD_SA fails.
>>
>> Now I would never suggest that anyone use a traffic selectors type from
>> the private range (241-255) which is almost guaranteed to fail...
>>
>> Yoav
>> 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] IKEv2 Certificate Information

[Raj Singh]

Hi Anil,

Please find my reply inline.

On Tue, May 19, 2009 at 10:55 AM, Anil Maguluri <
anil.magul...@lntinfotech.com> wrote:

>
> Hi All,
>
> I would like to know what are the different certificates to support in
> IKEv2?

  raj> The most commonly supported certificate forms are:
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-03
Section 3.6
..

Certificate Encoding Value
  

  *X.509 Certificate - Signature4
*  *Hash and URL of X.509 certificate12*



> Is it mandatory to support CERT and CERTREQ payloads in IKE_AUTH message?

   raj> NO.

>
> If yes, please let me know the supported Certificates information and
> corresponding
> RFC numbers.
>
> Also please let me know IKEv2 opensource code which contains the
> certificates
> information.

   raj> StrongSwan and Racoon2 supports most of the features of IKEv2
   http://www.strongswan.org/
   http://www.racoon2.wide.ad.jp/w/


> Thanks for your support.
>
> Regards,
> Anil Kumar Maguluri
> __
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Thanks,
Raj
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IKEv2 Certificate Information

[Raj Singh]

Hi Anil,

X.509 is one authentication method like pre-shared keys for a peer to prove
it's identity.
So if CERT authentication method is configured in your IKEv2 policy, you
know that you have send CERTREQ and generate AUTH payload based on your
certificate. You can have just Pre-Shared Keys based authentication method
to build VPN.

Thanks,
Raj

On Tue, May 19, 2009 at 11:37 AM, Anil Maguluri <
anil.magul...@lntinfotech.com> wrote:

>
> Hi Raj,
>
> Thanks for your response.
>
> How IKEv2 will get the X.509 CERTIFICATE information (interface)?
> is it mandatory to develop VPN based PKI system?
>
> Regards,
> Anil Kumar Maguluri
>
>
>
>
>  *Raj Singh *
>
> 05/19/2009 11:28 AM
>   To
> Anil Maguluri 
>  cc
> ipsec@ietf.org  Subject
> Re: [IPsec] IKEv2 Certificate Information
>
>
>
>
> Hi Anil,
>
> Please find my reply inline.
>
> On Tue, May 19, 2009 at 10:55 AM, Anil Maguluri <*
> anil.magul...@lntinfotech.com* > wrote:
>
> Hi All,
>
> I would like to know what are the different certificates to support in
> IKEv2?
>   raj> The most commonly supported certificate forms are:*
> **http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-03*<http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-03>
> Section 3.6
> ..
> Certificate Encoding Value
>  
>
>  *X.509 Certificate - Signature4*
>  *Hash and URL of X.509 certificate12*
>
> 
>
>
> Is it mandatory to support CERT and CERTREQ payloads in IKE_AUTH message?
>raj> NO.
>
> If yes, please let me know the supported Certificates information and
> corresponding
> RFC numbers.
>
> Also please let me know IKEv2 opensource code which contains the
> certificates
> information.
>raj> StrongSwan and Racoon2 supports most of the features of IKEv2
>*http://www.strongswan.org/* <http://www.strongswan.org/>
>*http://www.racoon2.wide.ad.jp/w/* <http://www.racoon2.wide.ad.jp/w/>
>
>
> Thanks for your support.
>
> Regards,
> Anil Kumar Maguluri
> __
>
> ___
> IPsec mailing list*
> **ip...@ietf.org* *
> **https://www.ietf.org/mailman/listinfo/ipsec*<https://www.ietf.org/mailman/listinfo/ipsec>
>
> Thanks,
> Raj
>
> __
>
> __
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] FW: I-D Action:draft-nir-ike-nochild-00.txt

[Raj Singh]

Hi Yoav,

1. In section5, why we need N[ADDITIONAL_TS_POSSIBLE] when we want to create
child sa?
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.
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.

Thanks,
Raj

On Thu, May 21, 2009 at 7:30 PM, Yoav Nir  wrote:

> Hi all
>
> Recently there's been some discussions about creating an IKE SA without
> child SAs (on purpose).
>
> I'm still not entirely convinced that this is necessary, but I have
> submitted this draft, and would like to hear comments about it.  Does it
> fill the need that some people on this mailing list expressed?
>
> Thanks
>
> Yoav
>
> -Original Message-
> From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org]
> On Behalf Of internet-dra...@ietf.org
> Sent: Thursday, May 21, 2009 3:45 PM
> To: i-d-annou...@ietf.org
> Subject: I-D Action:draft-nir-ike-nochild-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>Title   : A Childless Initiation of the IKE SA
>Author(s)   : Y. Nir
>Filename: draft-nir-ike-nochild-00.txt
>Pages   : 6
>Date: 2009-05-21
>
> This document describes an extension to the IKEv2 protocol that allows an
> IKE SA to be created and authenticated without generating a child SA.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nir-ike-nochild-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
>
>
> 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] Inconsistent usage of SA

[Raj Singh]

Hi Emre,

IKE SA is bi-directional i.e. one SA is used in both directions, initiator
to responder and responder to initiator.
CHILD_SAs i.e. IPsec SAs (AH, ESP) are uni-directional, one in each
direction. So we 2 IPsec SAs per connection.

Thanks,
Raj

On Fri, May 22, 2009 at 7:41 PM, Gunduzhan, Emre
wrote:

>  Greetings,
>
> I am new to this group, so I hope I am not raising an issue which was
> addressed earlier. I was reading draft-ietf-ipsecme-ikev2bis, and I came
> across some inconsistent terminology which I believe also exists in RFC
> 4306.
>
> RFC 4301 defines a SA as a simplex "connection", and states that (section
> 4.1):
> "To secure typical, bi-directional communication between two IPsec-enabled
> systems, a pair of SAs (one in each direction) is required. IKE explicitly
> creates SA pairs in recognition of this common usage requirement."
>
> However in an example scenario in section 2.9.1 of 
> draft-ietf-ipsecme-ikev2bis,
> it seems that an SA can be used to carry traffic in both directions:
> " Suppose that host A has a policy whose effect is that traffic to
> 192.0.1.66 is sent via host B encrypted using AES, and traffic to all other
> hosts in 192.0.1.0/24 is also sent via B, but must use 3DES.  Suppose also
> that host B accepts any combination of AES and 3DES.
>
>  If host A now proposes an SA that uses 3DES, and includes TSr containing
> (192.0.1.0-192.0.1.255), this will be accepted by host B. Now, host B can
> also use this SA to send traffic from 192.0.1.66, but those packets will be
> dropped by A since it requires the use of AES for those traffic.  Even if
> host A creates a new SA only for 192.0.1.66 that uses AES, host B may freely
> continue to use the first SA for the traffic.  In this situation, when
> proposing the SA, host A should have followed its own policy, and included a
> TSr containing ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead."
>
> Because of the same issue, when RFC 4306 or draft-ietf-ipsecme-ikev2bis
> talks about creating an IKE SA, this would imply that the IKE SA would be a
> simplex "connection". Similarly, it is not clear from RFC 4306 or
> draft-ietf-ipsecme-ikev2bis whether a CREATE_CHILD_SA exchange (or, the
> initial IKE_AUTH exchange) creates a single SA, i.e. a simplex "connection",
> or a pair of SAs.
>
> Can someone please clarify which usage is correct? Would the workgroup
> consider resolving this ambiguity in the revision to IKEv2?
>
> Thanks and best regards,
> Emre
>
> --
>  Emre Gunduzhan, Ph.D
> The Johns Hopkins University Applied Physics Laboratory
> Applied Information Sciences Department
> Communication and Networking Systems Group (VCS)
>
>
>
>
> ___
> 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] FW: I-D Action:draft-nir-ike-nochild-00.txt

[Raj Singh]

Hi Yoav,

On Sun, May 24, 2009 at 3:38 PM, Yoav Nir  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

Re: [IPsec] Inconsistent usage of SA

[Raj Singh]

Hi Emre,


On Tue, May 26, 2009 at 6:38 PM, Gunduzhan, Emre
wrote:

>  Steve,
>
> Thanks for the clarification. So, at the end of the initial IKE_AUTH
> exchange, there will (typically) be a pair of CHILD SAs created, one in each
> direction, is this correct?
>
 Yes.

> That is, you never create a single SA by IKE_AUTH or CREATE_CHILD_SA, and
> create another SA in the other direction by a subsequent CREATE_CHILD_SA?
>
 We create a pair of SA, one for inbound and one for outbound traffic. These
SAs will be uniquely identified on the peer by inside SPI and outside SPI.
The inside SPI on one peer will the outside SPI on other peer and vice
versa.
Yes, we create a pair of SA using CREATE_CHILD_SA. Also, CREATE_CHILD_SA is
used for REKEY of IKE SA, only in that case CREATE_CHILD_SA will create
single SA.

>
> This is really ambiguous in RFC 4306 (at least to me) and would be great if
> it can be clarified in the revised version.
>
> Thanks,
> Emre
>
Thanks,
Raj

>
>
>  --
>
>
>  *From:* Stephen Kent [mailto:k...@bbn.com]
> *Sent:* Sunday, May 24, 2009 9:38 PM
> *To:* Gunduzhan, Emre
> *Cc:* ipsec@ietf.org
> *Subject:* Re: [IPsec] Inconsistent usage of SA
>
>  At 10:11 AM -0400 5/22/09, Gunduzhan, Emre wrote:
>
> Content-Language: en-US
> Content-Type: multipart/alternative;
>  boundary="_000_068F06DC4D106941B297C0C5F9F446EA3CB241D203apless
> tripedo_"
>
> Greetings,
>
>
>
> I am new to this group, so I hope I am not raising an issue which was
> addressed earlier. I was reading draft-ietf-ipsecme-ikev2bis, and I came
> across some inconsistent terminology which I believe also exists in RFC
> 4306.
>
>
>
> RFC 4301 defines a SA as a simplex "connection", and states that (section
> 4.1):
>
> "To secure typical, bi-directional communication between two IPsec-enabled
> systems, a pair of SAs (one in each direction) is required. IKE explicitly
> creates SA pairs in recognition of this common usage requirement."
>
>
>
> However in an example scenario in section 2.9.1
> of draft-ietf-ipsecme-ikev2bis, it seems that an SA can be used to carry
> traffic in both directions:
>
> " Suppose that host A has a policy whose effect is that traffic to
> 192.0.1.66 is sent via host B encrypted using AES, and traffic to all other
> hosts in 192.0.1.0/24 is also sent via B, but must use 3DES.  Suppose also
> that host B accepts any combination of AES and 3DES.
>
>
> 4301 is correct. Sometimes folks refer to the pair of SAs that IKE always
> creates as an SA, but that is not the correct terminology.
>
> Steve
>
> ___
> 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

[IPsec] Questions on ikev2-redirect-10

[Raj Singh]

Hi Vijay,

I have some question on ikev2-redirect-10 draft.

In section 5,
--
Once the client sends an acknowledgment 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.  However, it should allow sufficient time for
   the client to setup the required security associations with the new
   security gateway.  This time period should be configurable on the
   gateway.
---

Suppose after sending N[REDIRECT] in case of Gateway initiated redirect,
there is a time gap for client to delete old SA and create new SA with
redirected Gateway.

During this time, IKE REKEY occurs from gateway or client, what should be
the behavior, should it REKEY on old SA or defer the rekey ?

Also, when deleting IKE SA, due to redirect, is there any way to know that
this delete is sue to redirect ?



Thanks,
Raj
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Questions on ikev2-redirect-10

[Raj Singh]

Hi Vijay,

On Thu, May 28, 2009 at 3:24 AM, Vijay Devarapalli wrote:

> Hi,
>
> On 5/26/09 10:10 PM, "Raj Singh" wrote:
>
> > Hi Vijay,
> >
> > I have some question on ikev2-redirect-10 draft.
> >
> > In section 5,
> > --
> > Once the client sends an acknowledgment 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.  However, it should allow sufficient time for
> >the client to setup the required security associations with the new
> >security gateway.  This time period should be configurable on the
> >gateway.
> > ---
> >
> > Suppose after sending N[REDIRECT] in case of Gateway initiated redirect,
> > there is a time gap for client to delete old SA and create new SA with
> > redirected Gateway.
> >
> > During this time, IKE REKEY occurs from gateway or client, what should be
> > the behavior, should it REKEY on old SA or defer the rekey ?
>
> The rekey should be deferred. The IKEv2 SA is going to be torn down anyway.

Can you make a mention of this in the draft ? According to me, we can make
it simple by
saying that after REDIRECT, IKE SA will be marked for deletion i.e. we will
send/accept only DELETE informational exchange on that SA.

>
>
> > Also, when deleting IKE SA, due to redirect, is there any way to know
> that
> > this delete is sue to redirect ?
>
> Well, the gateway redirected the client. If following that, there is a
> delete from the client, the gateway would know that the IKEv2 SA is being
> deleted because it redirected the client.
>
> Anyway, does it matter?
>
It does. There is a time gap between REDIRECT and DELETE for the IKE SA. If
any activity happens during that period due to valid reasons ( REKEY,
DELETION due to lifetime etc.), we will not be sure what to do ? Also, for
administrative purpose we need to know that DELETE happened due to REDIRECT
or valid reasons.
Accepting only DELETE after REDIRECT solves all these problems.

>
> Vijay
>
> Thanks,
Raj
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Questions on ikev2-redirect-10

[Raj Singh]

A gentle reminder.

On Thu, May 28, 2009 at 8:37 AM, Raj Singh  wrote:

> Hi Vijay,
>
> On Thu, May 28, 2009 at 3:24 AM, Vijay Devarapalli wrote:
>
>> Hi,
>>
>> On 5/26/09 10:10 PM, "Raj Singh" wrote:
>>
>> > Hi Vijay,
>> >
>> > I have some question on ikev2-redirect-10 draft.
>> >
>> > In section 5,
>> > --
>> > Once the client sends an acknowledgment 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.  However, it should allow sufficient time for
>> >the client to setup the required security associations with the new
>> >security gateway.  This time period should be configurable on the
>> >gateway.
>> > ---
>> >
>> > Suppose after sending N[REDIRECT] in case of Gateway initiated redirect,
>> > there is a time gap for client to delete old SA and create new SA with
>> > redirected Gateway.
>> >
>> > During this time, IKE REKEY occurs from gateway or client, what should
>> be
>> > the behavior, should it REKEY on old SA or defer the rekey ?
>>
>> The rekey should be deferred. The IKEv2 SA is going to be torn down
>> anyway.
>
> Can you make a mention of this in the draft ? According to me, we can make
> it simple by
> saying that after REDIRECT, IKE SA will be marked for deletion i.e. we will
> send/accept only DELETE informational exchange on that SA.
>
>>
>>
>> > Also, when deleting IKE SA, due to redirect, is there any way to know
>> that
>> > this delete is sue to redirect ?
>>
>> Well, the gateway redirected the client. If following that, there is a
>> delete from the client, the gateway would know that the IKEv2 SA is being
>> deleted because it redirected the client.
>>
>> Anyway, does it matter?
>>
> It does. There is a time gap between REDIRECT and DELETE for the IKE SA. If
> any activity happens during that period due to valid reasons ( REKEY,
> DELETION due to lifetime etc.), we will not be sure what to do ? Also, for
> administrative purpose we need to know that DELETE happened due to REDIRECT
> or valid reasons.
> Accepting only DELETE after REDIRECT solves all these problems.
>
>>
>> Vijay
>>
>> Thanks,
> Raj
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Final comments for ikev2-redirect-10

[Raj Singh]

Hi Team,

I agree with Pasi.

Regards,
Raj

On Fri, Jun 5, 2009 at 5:12 PM,  wrote:

> Vijay Devarapalli wrote:
>
> > > And having these two cases is more complex than having just one
> > > (IKE_SA is not used for any more exchanges). What benefits does
> > > this additional complexity (both in spec and in implementation)
> > > get us?
> > >
> > > If nothing, let's just remove it
> >
> > When the AUTH payloads are exchanged and verified, the IKEv2 SA is
> > valid.  This seems straightforward. We are not doing anything out of
> > the ordinary here by not invalidating the IKEv2 SA just because the
> > gateway sent the REDIRECT payload to the client.
> >
> > I can imagine extensions tomorrow that would let the client convey
> > additional information using the IKEv2 SA to the gateway, after the
> > gateway had sent a REDIRECT payload to the client.
>
> What do you mean by "valid"? So the client could potentially ignore
> the redirect (in the last IKE_AUTH response), and continue using the
> IKE_SA (at least for some time) for other exhanges?
>
> AFAIK, the current text is *not* supposed to allow that -- but
> it seems it is indeed quite unclear.
>
> Best regards,
> Pasi
>
> ___
> 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] FW: I-D Action:draft-nir-ike-nochild-02.txt

[Raj Singh]

Hi Yoav,

Please find my inputs:

1. In section 3:

.

   A supporting responder that advertised the VID payload in the
   IKE_INIT response MUST process a modified IKE_AUTH request, and MUST
   reply with a modified IKE_AUTH response.  Such a responder MUST NOT
   reply with a modified IKE_AUTH response if the initiator did not send
   a modified IKE_AUTH request.
   A supporting responder that has been configured not to support this
   extension to the protocol MUST behave as the same as if it didn't
   support this extension.  It MUST NOT advertise the capability with a
   VID payload, and it SHOULD reply with an INVALID_SYNTAX Notify
   payload if the client sends an IKE_AUTH request that is modified as
   described in Section 5.




It does not fully clarifies exactly the behavior of the responder if a
faulty initiator send modified IKE_AUTH request without responder
sending NO_CHILD
in IKE_SA_INIT response ? Shall in that case responder should bring UP
the only IKE SA
and send modified response or send INVALID_SYNTAX notify and tear down
the SA? More
clarity needed here. Also we can replace SHOULD to MUST for INVALID_SYNTAX.

2. In whole document, IKE_SA_INIT exchange has been termed as IKE_INIT,
change it to IKE_SA_INIT.

3. In section 4, hash string "Can do IKE_AUTH without child SA payloads
also" seems to more close to what draft says :-)

Thanks & Regards,
Raj

On Thu, Jun 18, 2009 at 2:38 AM, Yoav Nir  wrote:

> Hi all
>
> version -02 of this private submission draft, with two additional
> co-authors and some more use cases.
>
> Enjoy
>
> Yoav
> 
> From: i-d-announce-boun...@ietf.org [i-d-announce-boun...@ietf.org] On
> Behalf Of internet-dra...@ietf.org [internet-dra...@ietf.org]
> Sent: Thursday, June 18, 2009 00:00
> To: i-d-annou...@ietf.org
> Subject: I-D Action:draft-nir-ike-nochild-02.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>Title   : A Childless Initiation of the IKE SA
>Author(s)   : Y. Nir, et al.
>Filename: draft-nir-ike-nochild-02.txt
>Pages   : 7
>Date: 2009-06-17
>
> This document describes an extension to the IKEv2 protocol that
> allows an IKE SA to be created and authenticated without generating a
> child SA.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nir-ike-nochild-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
>
> 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] FW: I-D Action:draft-nir-ike-nochild-02.txt

[Raj Singh]

Hi Yoav,

On Thu, Jun 18, 2009 at 11:24 AM, Raj Singh  wrote:

> Hi Yoav,
>
> Please find my inputs:
>
> 1. In section 3:
>
> .
>
>A supporting responder that advertised the VID payload in the
>IKE_INIT response MUST process a modified IKE_AUTH request, and MUST
>
>reply with a modified IKE_AUTH response.  Such a responder MUST NOT
>reply with a modified IKE_AUTH response if the initiator did not send
>a modified IKE_AUTH request.
>A supporting responder that has been configured not to support this
>
>extension to the protocol MUST behave as the same as if it didn't
>support this extension.  It MUST NOT advertise the capability with a
>VID payload, and it SHOULD reply with an INVALID_SYNTAX Notify
>payload if the client sends an IKE_AUTH request that is modified as
>
>described in Section 5.
>
>
> 
>
> It does not fully clarifies exactly the behavior of the responder if a
> faulty initiator send modified IKE_AUTH request without responder sending 
> NO_CHILD
> in IKE_SA_INIT response ? Shall in that case responder should bring UP the 
> only IKE SA
>
> and send modified response or send INVALID_SYNTAX notify and tear down the 
> SA? More
> clarity needed here. Also we can replace SHOULD to MUST for INVALID_SYNTAX.
>
> 2. In whole document, IKE_SA_INIT exchange has been termed as IKE_INIT,
> change it to IKE_SA_INIT.
>
> 3. In section 4, hash string "Can do IKE_AUTH without child SA payloads
> also" seems to more close to what draft says :-)

Also please make a mention of hashing algorithm for completeness.

>
>
> Thanks & Regards,
> Raj
>

With Regards,
Raj

>
> On Thu, Jun 18, 2009 at 2:38 AM, Yoav Nir  wrote:
>
>> Hi all
>>
>> version -02 of this private submission draft, with two additional
>> co-authors and some more use cases.
>>
>> Enjoy
>>
>> Yoav
>> 
>> From: i-d-announce-boun...@ietf.org [i-d-announce-boun...@ietf.org] On
>> Behalf Of internet-dra...@ietf.org [internet-dra...@ietf.org]
>> Sent: Thursday, June 18, 2009 00:00
>> To: i-d-annou...@ietf.org
>> Subject: I-D Action:draft-nir-ike-nochild-02.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>Title   : A Childless Initiation of the IKE SA
>>Author(s)   : Y. Nir, et al.
>>Filename: draft-nir-ike-nochild-02.txt
>>Pages   : 7
>>Date: 2009-06-17
>>
>> This document describes an extension to the IKEv2 protocol that
>> allows an IKE SA to be created and authenticated without generating a
>> child SA.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nir-ike-nochild-02.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>>
>> 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] I-D Action:draft-ietf-ipsecme-ikev2-redirect-11.txt

[Raj Singh]

Hi Padam,

It possible and avoidable by configuring a policy on client for MAX no. of
REDIRECTs.
Draft has a mention of this scenario in Section 10.

With Regards,
Raj

On Wed, Jul 1, 2009 at 4:24 PM, Padmakumar AV  wrote:

> Hi Vijay,
>
> I have a doubt regarding the usage of redirect during INIT exchange.
>
> An attacker in between spoke and hub spoofs the init exchange to anycast
> address and then redirects it to another FAKE-HUB1 by specifying unicast
> address of the FAKE-HUB1. FAKE-HUB1 subsequently redirects it to FAKE-HUB2
> and FAKE-HUB2 to FAKE-HUB3 and go on...
>
> Is that possible.
>
>
>
> Thanks
>
> Padmakumar
>
> On Tue, Jun 16, 2009 at 11:45 PM,  wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the IP Security Maintenance and Extensions
>> Working Group of the IETF.
>>
>>
>>Title   : Redirect Mechanism for IKEv2
>>Author(s)   : V. Devarapalli, K. Weniger
>>Filename: draft-ietf-ipsecme-ikev2-redirect-11.txt
>>Pages   : 16
>>Date: 2009-06-16
>>
>> IKEv2 is a protocol for setting up VPN tunnels from a remote location
>> to a gateway so that the VPN client can access services in the
>> network behind the gateway.  Currently there is no standard mechanism
>> specified that allows an overloaded VPN gateway or a VPN gateway that
>> is being shut down for maintenance to redirect the VPN client to
>> attach to another gateway.  This document proposes a redirect
>> mechanism for IKEv2.  The proposed mechanism can also be used in
>> Mobile IPv6 to enable the home agent to redirect the mobile node to
>> another home agent.
>>
>> A URL for this Internet-Draft is:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-11.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>> ___
>> 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
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-11.txt

[Raj Singh]

Hi Padma,

By having a policy for MAX no of re-direct means when spoke reaches max no
of re-directs it will come to know that either it is under attack or there
is some misconfiguration. Then spoke can choose to stop trying connection
with anycast address and fall back to some other VPN gateway for connection.

Thanks,
Raj



On Thu, Jul 2, 2009 at 8:28 AM, Padmakumar AV  wrote:

> Hi Raj,
> The case I mentioned is with usage of redirect during init exchange
> destined to anycast. The router that tries to resolve the anycast address
> has no clue about this as it is syntactically same as that of unicast. But
> an attacker who has access to the link, precisely where anycast resolution
> happens can always set override bit in the NA and win the resolution. He may
> not be capable to drop the packet as mentioned in Section 10 but will be
> able to redirect it either to a victim or another node or do continuous
> redirects. I don't understand how the spokes resolve this problem by having
> a policy at the spoke side to restrict the maximum number of redirects as
> its final plan is to connect to a hub.
>
> Thanks
> Padmakumar
>
>
> On Wed, Jul 1, 2009 at 6:58 PM, Raj Singh  wrote:
>
>> Hi Padam,
>>
>> It possible and avoidable by configuring a policy on client for MAX no. of
>> REDIRECTs.
>> Draft has a mention of this scenario in Section 10.
>>
>> With Regards,
>> Raj
>>
>>
>> On Wed, Jul 1, 2009 at 4:24 PM, Padmakumar AV wrote:
>>
>>> Hi Vijay,
>>>
>>> I have a doubt regarding the usage of redirect during INIT exchange.
>>>
>>> An attacker in between spoke and hub spoofs the init exchange to anycast
>>> address and then redirects it to another FAKE-HUB1 by specifying unicast
>>> address of the FAKE-HUB1. FAKE-HUB1 subsequently redirects it to FAKE-HUB2
>>> and FAKE-HUB2 to FAKE-HUB3 and go on...
>>>
>>> Is that possible.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Padmakumar
>>>
>>> On Tue, Jun 16, 2009 at 11:45 PM,  wrote:
>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>> This draft is a work item of the IP Security Maintenance and Extensions
>>>> Working Group of the IETF.
>>>>
>>>>
>>>>Title   : Redirect Mechanism for IKEv2
>>>>Author(s)   : V. Devarapalli, K. Weniger
>>>>Filename: draft-ietf-ipsecme-ikev2-redirect-11.txt
>>>>Pages   : 16
>>>>Date: 2009-06-16
>>>>
>>>> IKEv2 is a protocol for setting up VPN tunnels from a remote location
>>>> to a gateway so that the VPN client can access services in the
>>>> network behind the gateway.  Currently there is no standard mechanism
>>>> specified that allows an overloaded VPN gateway or a VPN gateway that
>>>> is being shut down for maintenance to redirect the VPN client to
>>>> attach to another gateway.  This document proposes a redirect
>>>> mechanism for IKEv2.  The proposed mechanism can also be used in
>>>> Mobile IPv6 to enable the home agent to redirect the mobile node to
>>>> another home agent.
>>>>
>>>> A URL for this Internet-Draft is:
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-11.txt
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> Below is the data which will enable a MIME compliant mail reader
>>>> implementation to automatically retrieve the ASCII version of the
>>>> Internet-Draft.
>>>>
>>>>
>>>> ___
>>>> 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
>>>
>>>
>>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] IKEv2 bis section order

[Raj Singh]

Hi Team,

I think we can have Introduction and IKE Protocol View [today's Sec.
1.2-1.5] as Section 1 and move Usage scenario to IKE Protocol Details and
Variations.
Usage scenario can make more sense after brief protocol description and it's
difference with IKEv1.

Regards,
Raj

On Thu, Jul 2, 2009 at 2:11 AM, Paul Hoffman  wrote:

> At 7:36 PM +0300 7/1/09, Yaron Sheffer wrote:
> >I'd like to propose:
> >
> >   1.  Introduction
> > 1.1.  Usage Scenarios
> >   1.1.1.  Security Gateway to Security Gateway Tunnel Mode
> >   1.1.2.  Endpoint-to-Endpoint Transport Mode
> >   1.1.3.  Endpoint to Security Gateway Tunnel Mode
> >   1.1.4.  Other Scenarios
> > 1.2.  Requirements Terminology
> >
> >   2.  IKE Protocol Overview (or "Essentials") [today's Sec. 1.2-1.5]
> > 2.1.  The Initial Exchanges
> > 2.2.  The CREATE_CHILD_SA Exchange
> >   2.2.1.  Creating New Child SAs with the CREATE_CHILD_SA
> >   Exchange
> >   2.2.2.  Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
> >   2.2.3.  Rekeying Child SAs with the CREATE_CHILD_SA
> >   Exchange
> > 2.3.  The INFORMATIONAL Exchange
> >   2.3.1.  Deleting an SA with INFORMATIONAL Exchanges
> > 2.4.  Informational Messages outside of an IKE SA
> >
> >   3.  IKE Protocol Details and Variations [today's Sec. 2]
> >
> >   Appendix X: Differences Between RFC 4306 and This Document [today's
> Sec.
> >1.7]
>
> A different idea is to simply rename Section 1 "IKE Protocol Overview", and
> move the requirements terminology (which is, in essence, boilerplate that
> most people ignore anyway) and the differences to appendixes.
>
> >Do you see value in this, or do you prefer keeping the existing order?
>
> I see only minor value to the original proposal, and a high cost to me (the
> editor). I think my alternate proposal isn't so onerous, but am happy to
> follow Yaron's proposal if people really like it.
>
> --Paul Hoffman, Director
> --VPN Consortium
> ___
> 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] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

[Raj Singh]

Hi Yoav,

Mostly the Initiator will decide that it wants to bring UP only IKE SA
without child SA.
But currently there is no notify/VID from Initiator to Responder to indicate
that initiator wants to bring only IKE SA. Even if responder does not
supports "childless IKE_AUTH", it will process IKE_SA_INIT, involding CPU
intensive D-H calculations, and send IKE_SA_INIT response without "childless
VID" payload.

By introducing a notify/VID payload from Initiator that it wants to bring UP
only IKE SA without child SA wil ease the processing ar Responder side. If
responder does not support "childless IKE_AUTH", it can send INVALID_SYNTAX.
Then, Initiator will wait for "Child SA" info to be available to bring UP
both IKE and child SA, normally as mentioned in RFC 4306.

Thanks,
Raj

On Thu, Jul 2, 2009 at 1:42 AM, Yoav Nir  wrote:

> Hi all.
>
> This is the fourth iteration of this draft.  New in this iteration
>  - Another co-author
>  - Changed the name, so that this item is considered in the rechartering
> discussion
>  - Fixed some notation and some discussion based on comments from the list
>
> Yoav
> 
> From: i-d-announce-boun...@ietf.org [i-d-announce-boun...@ietf.org] On
> Behalf Of internet-dra...@ietf.org [internet-dra...@ietf.org]
> Sent: Wednesday, July 01, 2009 12:15
> To: i-d-annou...@ietf.org
> Subject: I-D Action:draft-nir-ipsecme-childless-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>Title   : A Childless Initiation of the IKE SA
>Author(s)   : Y. Nir, et al.
>Filename: draft-nir-ipsecme-childless-00.txt
>Pages   : 7
>Date: 2009-07-01
>
> This document describes an extension to the IKEv2 protocol that
> allows an IKE SA to be created and authenticated without generating a
> child SA.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nir-ipsecme-childless-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
>
> 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] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

[Raj Singh]

Hi Yaron,

I agree with you.
Your suggestion of having "critical" bit set on childless notify/VID payload
from initiator in IKE_SA_INIT exchange will define the bahavior as mentioned
below.

If initiator want to childless IKE_AUTH, it will send  CHILDLESS_IKE_AUTH
notify/VID payload having "critical" flag SET in IKE_SA_INIT request.

1. It will help responder not to process the IKE_SA_INIT exchange if it does
not support childless IKE_AUTH.

"The responder MUST reject IKE_SA_INIT exchange if it receives
CHILDLESS_IKE_AUTH notify/VID payload in IKE_SA_INIT exchange from initiator
if responder does not support childless IKE_AUTH and in response to the
IKE_SA_INIT exchange containing CHILDLESS_IKE_AUTH it MUST send
UNSUPPORTED_CRITICAL_PAYLOAD, the notification data will contain two-octet
unsupported notify/VID payload type i.e. CHILDLESS_IKE_AUTH."

2. It will help initiator to not to go ahead with childless IKE_AUTH if
responder doesn't support it wtithout procesing IKE_SA_INIT response.

With Regards,
Raj

On Sat, Jul 4, 2009 at 12:16 AM, Yaron Sheffer wrote:

>  Hi Raj,
>
>
>
> It sounds like you want a critical payload (RFC 4306, Sec. 2.5), probably a
> payload with no data. In fact the draft could specify both options, the
> current VID and such a payload, and leave it to the Initiator to decide
> which behavior it prefers. Different scenarios might call for different
> behaviors.
>
>
>
> Thanks,
>
> Yaron
>
>
>   ------
>
> *From:* ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] *On Behalf
> Of *Raj Singh
> *Sent:* Friday, July 03, 2009 16:51
> *To:* Yoav Nir
> *Cc:* ipsec@ietf.org
> *Subject:* Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
>
>
>
> Hi Yoav,
>
> Mostly the Initiator will decide that it wants to bring UP only IKE SA
> without child SA.
> But currently there is no notify/VID from Initiator to Responder to
> indicate that initiator wants to bring only IKE SA. Even if responder does
> not supports "childless IKE_AUTH", it will process IKE_SA_INIT, involding
> CPU intensive D-H calculations, and send IKE_SA_INIT response without
> "childless VID" payload.
>
> By introducing a notify/VID payload from Initiator that it wants to bring
> UP only IKE SA without child SA wil ease the processing ar Responder side.
> If responder does not support "childless IKE_AUTH", it can send
> INVALID_SYNTAX. Then, Initiator will wait for "Child SA" info to be
> available to bring UP both IKE and child SA, normally as mentioned in RFC
> 4306.
>
> Thanks,
> Raj
>
> On Thu, Jul 2, 2009 at 1:42 AM, Yoav Nir  wrote:
>
> Hi all.
>
> This is the fourth iteration of this draft.  New in this iteration
>  - Another co-author
>  - Changed the name, so that this item is considered in the rechartering
> discussion
>  - Fixed some notation and some discussion based on comments from the list
>
> Yoav
> 
> From: i-d-announce-boun...@ietf.org [i-d-announce-boun...@ietf.org] On
> Behalf Of internet-dra...@ietf.org [internet-dra...@ietf.org]
> Sent: Wednesday, July 01, 2009 12:15
> To: i-d-annou...@ietf.org
> Subject: I-D Action:draft-nir-ipsecme-childless-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>Title   : A Childless Initiation of the IKE SA
>Author(s)   : Y. Nir, et al.
>Filename: draft-nir-ipsecme-childless-00.txt
>Pages   : 7
>Date: 2009-07-01
>
> This document describes an extension to the IKEv2 protocol that
> allows an IKE SA to be created and authenticated without generating a
> child SA.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nir-ipsecme-childless-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
>
> Email secured by Check Point
>
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
>
> Scanned by Check Point Total Security Gateway.
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

[Raj Singh]

Hi Yaron,

Its clear that critical bit refer to the payload, than to its content. Point
well taken.
But i am not able to understand why we can't define "critical" bit for new
CHILDLESS_IKE_AUTH notify/VID payload ?

With Regards,
Raj

On Sat, Jul 4, 2009 at 6:42 PM, Yaron Sheffer  wrote:

>  Nope. The Critical bit refers to the payload, rather than to its
> contents, and in fact cannot be set for payloads defined in RFC 4306 (such
> as VID and Notify). So you need to define a NEW payload to benefit from it.
>
>
>
> Thanks,
>
> Yaron
>
>
>   --
>
> *From:* Raj Singh [mailto:rsjen...@gmail.com]
> *Sent:* Saturday, July 04, 2009 13:37
> *To:* Yaron Sheffer
> *Cc:* Yoav Nir; ipsec@ietf.org
>
> *Subject:* Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
>
>
>
> Hi Yaron,
>
> I agree with you.
> Your suggestion of having "critical" bit set on childless notify/VID
> payload from initiator in IKE_SA_INIT exchange will define the bahavior as
> mentioned below.
>
> If initiator want to childless IKE_AUTH, it will send  CHILDLESS_IKE_AUTH
> notify/VID payload having "critical" flag SET in IKE_SA_INIT request.
>
> 1. It will help responder not to process the IKE_SA_INIT exchange if it
> does not support childless IKE_AUTH.
>
> "The responder MUST reject IKE_SA_INIT exchange if it receives
> CHILDLESS_IKE_AUTH notify/VID payload in IKE_SA_INIT exchange from initiator
> if responder does not support childless IKE_AUTH and in response to the
> IKE_SA_INIT exchange containing CHILDLESS_IKE_AUTH it MUST send
> UNSUPPORTED_CRITICAL_PAYLOAD, the notification data will contain two-octet
> unsupported notify/VID payload type i.e. CHILDLESS_IKE_AUTH."
>
> 2. It will help initiator to not to go ahead with childless IKE_AUTH if
> responder doesn't support it wtithout procesing IKE_SA_INIT response.
>
> With Regards,
> Raj
>
> On Sat, Jul 4, 2009 at 12:16 AM, Yaron Sheffer 
> wrote:
>
> Hi Raj,
>
>
>
> It sounds like you want a critical payload (RFC 4306, Sec. 2.5), probably a
> payload with no data. In fact the draft could specify both options, the
> current VID and such a payload, and leave it to the Initiator to decide
> which behavior it prefers. Different scenarios might call for different
> behaviors.
>
>
>
> Thanks,
>
> Yaron
>
>
>   --
>
> *From:* ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] *On Behalf
> Of *Raj Singh
> *Sent:* Friday, July 03, 2009 16:51
> *To:* Yoav Nir
> *Cc:* ipsec@ietf.org
> *Subject:* Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
>
>
>
> Hi Yoav,
>
> Mostly the Initiator will decide that it wants to bring UP only IKE SA
> without child SA.
> But currently there is no notify/VID from Initiator to Responder to
> indicate that initiator wants to bring only IKE SA. Even if responder does
> not supports "childless IKE_AUTH", it will process IKE_SA_INIT, involding
> CPU intensive D-H calculations, and send IKE_SA_INIT response without
> "childless VID" payload.
>
> By introducing a notify/VID payload from Initiator that it wants to bring
> UP only IKE SA without child SA wil ease the processing ar Responder side.
> If responder does not support "childless IKE_AUTH", it can send
> INVALID_SYNTAX. Then, Initiator will wait for "Child SA" info to be
> available to bring UP both IKE and child SA, normally as mentioned in RFC
> 4306.
>
> Thanks,
> Raj
>
> On Thu, Jul 2, 2009 at 1:42 AM, Yoav Nir  wrote:
>
> Hi all.
>
> This is the fourth iteration of this draft.  New in this iteration
>  - Another co-author
>  - Changed the name, so that this item is considered in the rechartering
> discussion
>  - Fixed some notation and some discussion based on comments from the list
>
> Yoav
> 
> From: i-d-announce-boun...@ietf.org [i-d-announce-boun...@ietf.org] On
> Behalf Of internet-dra...@ietf.org [internet-dra...@ietf.org]
> Sent: Wednesday, July 01, 2009 12:15
> To: i-d-annou...@ietf.org
> Subject: I-D Action:draft-nir-ipsecme-childless-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>Title   : A Childless Initiation of the IKE SA
>Author(s)   : Y. Nir, et al.
>Filename: draft-nir-ipsecme-childless-00.txt
>Pages   : 7
>Date: 2009-07-01
>
> This document describes an extension to the IKEv2 protocol that
> allows a

Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

[Raj Singh]

Hi Yoav,

Please find my input inline .

With Regards,
Raj

On Sun, Jul 5, 2009 at 2:33 AM, Yoav Nir  wrote:

> Hi Raj
>
> The ordinary thing for a responder to do with unrecognized Notifies/VIDs is
> to ignore them. So the only responder that will behave as you suggest is one
> that supports this extension, but is configured not to.

 Yes, if responder understands childless IKE_AUTH from initiator, it
will behave as mentioned in my previous mail, if NOT and it does not support
childless IKE_AUTH [only responder not supporting childless extention], then
initiator will notice missing childless notify/VID and can stop the
transactions for the SA. But it will help responders, supporting this
extentions and applying policies.

>
>
> At least for the remote access client, it makes sense for a client that
> faces both supporting and non-supporting gateways to have a "dummy" proposal
> for a useless child SA, for example ICMP from the client to the gateway. It
> doesn't really matter if the proposal is accepted or rejected, because the
> client does not need the traffic.

  What's the usecase ?

>
>
> In any case, an initiator that insists on a childless IKE SA contacting a
> gateway that does not support the extension is a misconfiguration. I don't
> believe we should go to great lengths (especially the new critical payload
> that Yaron is proposing) to save work in such a misconfiguration case.

 How it can be a misconfiguration, The gateway can put some policy to
enable/disable childless IKE_AUTH based on "load" on gateway. Yes, i agree,
new crittical payload, we can avoid.

>
>
> If we do think it's important, the "right" way is for the Initiator to send
> the VID, for the responder to only send the VID if it (a) supports the
> extension *and* (b) has seen the VID from the initiator. We could even
> require that the initiator be prepared to continue with a non-supporting
> gateway, but I'm not sure that's a good idea.

 The whole idea is:
initiator to send childless notify/VID when it want to bring up "ONLY" IKE
SA i.e. it is not hit by traffic or "dummy" payload. This will avoid
unnecessary processing of IKE_SA_INIT at responder when responder does not
support childless IKE_AUTH. This is most likely usecase of chiless IKE_AUTH
in VPN scenarios.
The behavior remains similar as mentioned in my previous mail except
"critical" bit as it needs to define new payload type which even i want to
avoid. Its just a simple notify/VID payload with no associated data and
easing the work at initiator and responder. Its can see goodness in idea.
When initiator has dummy proposal  ready, the initiator need not to send
childless notify/VID payload.

>
>
> 
> From: Raj Singh [rsjen...@gmail.com]
> Sent: Friday, July 03, 2009 16:51
> To: Yoav Nir
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
>
> Hi Yoav,
>
> Mostly the Initiator will decide that it wants to bring UP only IKE SA
> without child SA.
> But currently there is no notify/VID from Initiator to Responder to
> indicate that initiator wants to bring only IKE SA. Even if responder does
> not supports "childless IKE_AUTH", it will process IKE_SA_INIT, involding
> CPU intensive D-H calculations, and send IKE_SA_INIT response without
> "childless VID" payload.
>
> By introducing a notify/VID payload from Initiator that it wants to bring
> UP only IKE SA without child SA wil ease the processing ar Responder side.
> If responder does not support "childless IKE_AUTH", it can send
> INVALID_SYNTAX. Then, Initiator will wait for "Child SA" info to be
> available to bring UP both IKE and child SA, normally as mentioned in RFC
> 4306.
>
> Thanks,
> Raj
>
> On Thu, Jul 2, 2009 at 1:42 AM, Yoav Nir  y...@checkpoint.com>> wrote:
> Hi all.
>
> This is the fourth iteration of this draft.  New in this iteration
>  - Another co-author
>  - Changed the name, so that this item is considered in the rechartering
> discussion
>  - Fixed some notation and some discussion based on comments from the list
>
> Yoav
> 
> From: i-d-announce-boun...@ietf.org<mailto:i-d-announce-boun...@ietf.org>
> [i-d-announce-boun...@ietf.org<mailto:i-d-announce-boun...@ietf.org>] On
> Behalf Of internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> [
> internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>]
> Sent: Wednesday, July 01, 2009 12:15
> To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>
> Subject: I-D Action:draft-nir-ipsecme-childless-00.txt
>
> A New Internet-Draft is availa

Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

[Raj Singh]

Hi Tero,

Thanks for your valuable inputs.
Please find re inputs inline. 

On Wed, Jul 8, 2009 at 1:00 AM, Tero Kivinen  wrote:

> Raj Singh writes:
> > Your suggestion of having "critical" bit set on childless notify/VID
> payload
> > from initiator in IKE_SA_INIT exchange will define the bahavior as
> mentioned
> > below.
>
> That is not correct way of using critical bit. Critical bit means that
> if it is set and the PAYLOAD TYPE is not understood, then
> UNSUPPORTED_CRITICAL_PAYLOAD error is reported. Every implementation
> will understand Notify and Vendor ID payloads, thus they will never
> return UNSUPPORTED_CRITICAL_PAYLOAD regardless what the contents of
> those payloads are.


I  was under impression that we can have "critical" bit in childless
IKE_AUTH notify/VID.
Even Yaron also clarified in same thread that we need new exchange type to
have "critical" bit on it.

>
>
> > If initiator want to childless IKE_AUTH, it will send  CHILDLESS_IKE_AUTH
> > notify/VID payload having "critical" flag SET in IKE_SA_INIT request.
>
> And complient implentation will do what to do as RFC4306 says ie:
>
>  ... MUST be ignored by the recipient if the recipient
>  understands the payload type code. MUST be set to zero for
>  payload types defined in this document. Note that the critical
>  bit applies to the current payload rather than the "next"
>  payload whose type code appears in the first octet. The
>  reasoning behind not setting the critical bit for payloads
>  defined in this document is that all implementations MUST
>  understand all payload types defined in this document and
>  therefore must ignore the Critical bit's value. Skipped payloads
>  are expected to have valid Next Payload and Payload Length
>  fields.
>
> The correct way to do is to make new exchange type for this new
> childless IKE_SA_INIT & IKE_AUTH. That way old implenentations will
> then know that they do not understand this new type and will drop the
> packets. This is if you really want the property that if responder
> does not understand chieldless IKE_AUTH you do not want to continue at
> all.
>
> I have not yet read the draft, as I have been too busy with working
> group drafts already, and I still do not know if this is really needed
> at all...


If we can't have "critical" bit inside associated data of childless
notify/VID,  then
new exchange type is a near possibility.
Please have a look at the use cases in the draft for need of this draft.

>
> --
> kivi...@iki.fi
>

With Regards,
Raj
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

[Raj Singh]

Hi Yoav,

So, we have 2 solutions:

1. New "Childless" payload with "critical" bit send by initiator
   Pros:
i. Helps initiator and responder to have finer policy to allow/deny
childless IKE_AUTH.
ii. Responder will not process IKE_SA_INIT if Initiator wants only
childless IKE_AUTH.
iii. Backward compatible.

   Cons:
i. Requires a NEW payload with NOT MUCH data in it.

2. New "childless" notify/VID with "critial" bit in associated data.
   Pros:
i. No need for NEW payload type.
   Cons:
i. NOT backward compatible.

The solution 1 looks GOOD to me.

With regards,
Raj

On Wed, Jul 8, 2009 at 11:19 AM, Yoav Nir  wrote:

>  Hi Raj
>
>
>
> What Yaron suggested, was to create a new payload type, and mark that as
> critical.
>
>  I don’t like either Yaron’s or Tero’s suggestions, as both lead to a kind
> of “take it or leave it” behavior. The initiator proposes doing “childless”,
> and if the responder does not agree, the IKE SA breaks.
>

>
> At least for the remote access case, where we want a stand-by IKE SA so
> that eventually we can have child SAs, this does not make sense. If the
> responder does not support childless, the initiator can still propose
> universal selectors, and the responder will narrow them down to a (possibly
> useless) valid SA.
>
>
>
> I think a better option is to have a notify/VID payload, with flags
> indicating whether a childless exchange is wanted, required or prohibited,
> and whether subsequent child SAs should be permitted.  This does still have
> a problem where the initiator requires that the IKE_AUTH be childless and
> the responder does not support the extension.
>
>
>
> Alternatively, we could adopt Yaron’s suggestion, and make a new payload,
> with a critical bit turned on or off according to requirement level. I don’t
> like having empty payloads, but I can’t back up this dislike with any good
> argument.
>
>
>
> Maybe when we make version 2.1 of IKE, we can add a “critical type” bit to
> the notification payload.
>  --
>
> *From:* Raj Singh [mailto:rsjen...@gmail.com]
> *Sent:* Wednesday, July 08, 2009 7:18 AM
> *To:* Tero Kivinen
> *Cc:* Yaron Sheffer; ipsec@ietf.org; Yoav Nir
> *Subject:* Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
>
>
>
> Hi Tero,
>
>
> Thanks for your valuable inputs.
> Please find re inputs inline. 
>
> On Wed, Jul 8, 2009 at 1:00 AM, Tero Kivinen  wrote:
>
> Raj Singh writes:
> > Your suggestion of having "critical" bit set on childless notify/VID
> payload
> > from initiator in IKE_SA_INIT exchange will define the bahavior as
> mentioned
> > below.
>
> That is not correct way of using critical bit. Critical bit means that
> if it is set and the PAYLOAD TYPE is not understood, then
> UNSUPPORTED_CRITICAL_PAYLOAD error is reported. Every implementation
> will understand Notify and Vendor ID payloads, thus they will never
> return UNSUPPORTED_CRITICAL_PAYLOAD regardless what the contents of
> those payloads are.
>
> 
>
> I  was under impression that we can have "critical" bit in childless
> IKE_AUTH notify/VID.
> Even Yaron also clarified in same thread that we need new exchange type to
> have "critical" bit on it.
>
>
>
>
> > If initiator want to childless IKE_AUTH, it will send  CHILDLESS_IKE_AUTH
> > notify/VID payload having "critical" flag SET in IKE_SA_INIT request.
>
> And complient implentation will do what to do as RFC4306 says ie:
>
>  ... MUST be ignored by the recipient if the recipient
>  understands the payload type code. MUST be set to zero for
>  payload types defined in this document. Note that the critical
>  bit applies to the current payload rather than the "next"
>  payload whose type code appears in the first octet. The
>  reasoning behind not setting the critical bit for payloads
>  defined in this document is that all implementations MUST
>  understand all payload types defined in this document and
>  therefore must ignore the Critical bit's value. Skipped payloads
>  are expected to have valid Next Payload and Payload Length
>  fields.
>
> The correct way to do is to make new exchange type for this new
> childless IKE_SA_INIT & IKE_AUTH. That way old implenentations will
> then know that they do not understand this new type and will drop the
> packets. This is if you really want the property that if responder
> does not understand chieldless IKE_AUTH you do not want to continue at
> all.
>
> I have not yet read the draft, as I have been too busy with working
> group

Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

[Raj Singh]

Hi Valery,

On Thu, Jul 9, 2009 at 1:13 PM, Valery Smyslov  wrote:

> Hi all,
>
> I think, adding new payload or exchange type is a real overkill for
> such a small extension.
> IKE has well defined mechanism for advertising/negotiating new
> extensions via VID or Notify.
> Other extensions (like MOBIKE) use it, so why multiply entities
> unnecessarily?
>
> Then, I'd rather leave a decision whether to proceed with childless or
> full versions
> of IKE_AUTH exchange completely at initiator's discretion. After all,
> it is he/she, who
> knows what happened - either user pressed "connect" button or there
> was a real packet.
> I think, responder should not have any policy on this - just capability.
> How could, for example, he/she insist on childless IKE SA if initiator
> has a real
> packet to protect? In this case it will either lead to denial of
> communication
> or initiator will probably create childless IKE SA following by
> CREATE_CHILD_SA,
> increasing unnecessary load on responder. Prohibiting childless IKE SA
> by responder
> doesn't make much sense either - nothing prevents initiator from following
> current behaviour - creating dummy IPsec SA and immediately deleting it.
> All responder has in this case is again unnecessary load on
> herself/himself.
>
> From my point of view, childless mode is just a usefull protocol
> optimization,
> and it is initiator, who must decide whether to use it. For this purpose
> peers must exchange VID/Notify payloads during IKE_SA_INIT, claiming their
> capabilities to proceed with childless IKE_AUTH. Then, if both
> sides support it, initiator decides whether to use it. In this case
> responder
> must be prepared to both versions of IKE_AUTH. If responder doesn't
> support this extension, it naturally doesn't send corresponding VID/Notify.
> At this point initiator must either proceed with current behaviour - dummy
> IPsec
> proposal (if she/he really wants IKE SA) or terminate exchange if she/he
> doesn't support current behaviour (in which case it is a misconfiguration).

The problem with this approach is if responder does not support this
extension,
then also it will process IKE_SA_INIT, (involving CPU intensive D-H
calculation)
which will be eventually dropped by initiator, if initiator wants to do only
childless IKE_AUTH.
Its good to be backward compatible.

>
>
> Regards,
> Valery Smyslov.
>
With Regards,
Raj

>
>
> 2009/7/8, Yoav Nir :
> > Hi Raj
> >
> > What Yaron suggested, was to create a new payload type, and mark that as
> > critical.
> >
> > I don't like either Yaron's or Tero's suggestions, as both lead to a kind
> of
> > "take it or leave it" behavior. The initiator proposes doing "childless",
> > and if the responder does not agree, the IKE SA breaks.
> >
> > At least for the remote access case, where we want a stand-by IKE SA so
> that
> > eventually we can have child SAs, this does not make sense. If the
> responder
> > does not support childless, the initiator can still propose universal
> > selectors, and the responder will narrow them down to a (possibly
> useless)
> > valid SA.
> >
> > I think a better option is to have a notify/VID payload, with flags
> > indicating whether a childless exchange is wanted, required or
> prohibited,
> > and whether subsequent child SAs should be permitted.  This does still
> have
> > a problem where the initiator requires that the IKE_AUTH be childless and
> > the responder does not support the extension.
> >
> > Alternatively, we could adopt Yaron's suggestion, and make a new payload,
> > with a critical bit turned on or off according to requirement level. I
> don't
> > like having empty payloads, but I can't back up this dislike with any
> good
> > argument.
> >
> > Maybe when we make version 2.1 of IKE, we can add a "critical type" bit
> to
> > the notification payload.
> > ____
> > From: Raj Singh [mailto:rsjen...@gmail.com]
> > Sent: Wednesday, July 08, 2009 7:18 AM
> > To: Tero Kivinen
> > Cc: Yaron Sheffer; ipsec@ietf.org; Yoav Nir
> > Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
> >
> > Hi Tero,
> >
> > Thanks for your valuable inputs.
> > Please find re inputs inline. 
> > On Wed, Jul 8, 2009 at 1:00 AM, Tero Kivinen
> > mailto:kivi...@iki.fi>> wrote:
> > Raj Singh writes:
> >> Your suggestion of having "critical" bit set on childless notify/VID
> >> payload
> >> from initiator in IKE_

[IPsec] [IKEv2] Questions on windowing in IKEv2

[Raj Singh]

Hi Group,

According to IKEv2bis-04, section 2.3

-

   An IKE endpoint MUST NOT exceed the peer's stated window size for
   transmitted IKE requests.  In other words, if the responder stated
   its window size is N, then when the initiator needs to make a request
   X, it MUST wait until it has received responses to all requests up
   through request X-N.  An IKE endpoint MUST keep a copy of (or be able
   to regenerate exactly) each request it has sent until it receives the
   corresponding response.  An IKE endpoint MUST keep a copy of (or be
   able to regenerate exactly) the number of previous responses equal to
   its declared window size in case its response was lost and the
   initiator requests its retransmission by retransmitting the request.



Now, suppose responder window size is N.
Initiator send a request (X-N) but Initiator does get
response for request no (X-N) say due to n/w flapping.
So initiator schedules this request for re-transmissions
but between the time intervals of re-transmission n/w comes UP
and request no. (X-N+1) to (X) goes fine i.e. these request get response.
Now, initiator wants to make another request i.e. request no.
(X+1). But according to draft it can't make that request as it has
not received the response for request no (X-N) even though there is
only one outstanding request in transit.

Also draft says:
---
 The SET_WINDOW_SIZE notification asserts that the sending endpoint is
   capable of keeping state for multiple outstanding exchanges,
   permitting the recipient to send multiple requests before getting a
   response to the first.


That means windowing is for outstanding request.
So in above mentioned scenario even though there is only 1
outstanding request and window size is N but we are not able to send
next request because of windowing definition.

Maybe i am missing something here.
Please elaborate the on the behavior in above scenario.

Regards,
Raj
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [IKEv2] Questions on windowing in IKEv2

[Raj Singh]

Hi Yoav,

Do you think this behavior contradicts with definition of windowing
mentioned in draft that if responder window is 3, initiator can have 3
outstanding request ?

Regards,
Raj

On Wed, Jul 22, 2009 at 1:09 PM, Yoav Nir  wrote:

>  Hi Raj.
>
>
>
> Too many variables, let’s assume values without loss of generality.
>
>
>
> Suppose N=3, and you have send requests 17, 18 and 19. Because of the
> network problems, you got responses for 18 and 19, but not **yet** for
> 17.
>
>
>
> What the draft (and RFC 4306) says, is that you keep retransmitting 17,
> until you get a response.  Before that, you can’t begin transmitting #20. If
> your retransmissions of #17 time out (after “at least a dozen
> retransmissions over at least 2 minutes”) then you assume that the peer has
> died, and silently discard the IKE SA.  This will usually not happen in the
> above scenario, because once the network is back, the responder will also
> reply to #17.
>
>
>
> Hope this helps
>
>
>  --
>
> *From:* ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] *On Behalf
> Of *Raj Singh
> *Sent:* Wednesday, July 22, 2009 8:52 AM
> *To:* ipsec@ietf.org
> *Subject:* [IPsec] [IKEv2] Questions on windowing in IKEv2
>
>
>
> Hi Group,
>
> According to IKEv2bis-04, section 2.3
>
> -
>
>An IKE endpoint MUST NOT exceed the peer's stated window size for
>
>transmitted IKE requests.  In other words, if the responder stated
>
>its window size is N, then when the initiator needs to make a request
>
>X, it MUST wait until it has received responses to all requests up
>
>through request X-N.  An IKE endpoint MUST keep a copy of (or be able
>
>to regenerate exactly) each request it has sent until it receives the
>
>corresponding response.  An IKE endpoint MUST keep a copy of (or be
>
>able to regenerate exactly) the number of previous responses equal to
>
>its declared window size in case its response was lost and the
>
>initiator requests its retransmission by retransmitting the request.
>
>
> 
>
> Now, suppose responder window size is N.
>
> Initiator send a request (X-N) but Initiator does get
>
> response for request no (X-N) say due to n/w flapping.
>
> So initiator schedules this request for re-transmissions
>
> but between the time intervals of re-transmission n/w comes UP
>
> and request no. (X-N+1) to (X) goes fine i.e. these request get response.
>
> Now, initiator wants to make another request i.e. request no.
>
> (X+1). But according to draft it can't make that request as it has
>
> not received the response for request no (X-N) even though there is
>
> only one outstanding request in transit.
>
>
> Also draft says:
>
> ---
>  The SET_WINDOW_SIZE notification asserts that the sending endpoint is
>
>capable of keeping state for multiple outstanding exchanges,
>
>permitting the recipient to send multiple requests before getting a
>
>response to the first.
> 
>
>
> That means windowing is for outstanding request.
>
> So in above mentioned scenario even though there is only 1
>
> outstanding request and window size is N but we are not able to send
>
> next request because of windowing definition.
>
>
> Maybe i am missing something here.
>
> Please elaborate the on the behavior in above scenario.
>
>
>
> Regards,
>
> Raj
>
>
>
> 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

[IPsec] Question regarding security considerations with NAT-T scenario in IKEv2

[Raj Singh]

Hi Group,

I have question regarding security considerations with NAT-T scenario in
IKEv2.
According to ikev2-bis-04, section 2.23
---


  There are cases where a NAT box decides to remove mappings that
  are still alive (for example, the keepalive interval is too long,
  or the NAT box is rebooted).  To recover in these cases, hosts

  that do not support other methods of recovery such as MOBIKE
  [MOBIKE 
],
and that are not behind a NAT, SHOULD send all packets

  (including retransmission packets) to the IP address and port from
  the last valid authenticated packet from the other end (that is,
  they should dynamically update the address).  A host behind a NAT

  SHOULD NOT do this because it opens a possible denial-of-service
  attack.  Any authenticated IKE packet or any authenticated UDP-
  encapsulated ESP packet can be used to detect that the IP address

  or the port has changed.  When IKEv2 is used with MOBIKE,
  dynamically updating the addresses described above interferes with
  MOBIKE's way of recovering from the same situation, so this method

  MUST NOT be used when MOBIKE is used.  See Section 3.8

of [MOBIKE 
]

  for more information.

--

1. Initiator is behind N(P)AT and float the port to (4500, 4500)

and send IKE_AUTH  with source port 4500 now N(P)AT changes source port
as 1024 but there is a man-in-the-middle who changes the port to other
host behind N(P)AT's port say 1025, still IKE_AUTH packet is authenticated.

The responder establishes the SA with destination port as 1025 instead of
1024 and sends the reply back to destination port 1025, so it will never
reach to original initiator . So the IKE SA will does not get established
on initiator But there is no mention of this DoS attack in the draft ?

2. The draft says the host that is NOT behind NAT SHOULD send packet to
IP address and port from which it received last authenticated packet.
A host behind behind a NAT SHOULD NOT do this because it opens a
DoS attack.

But how the location of host(Behind NAT or NOT) avoid DoS attack, say
when responder is having public IP, send an UDP encapsulated packet, some
man-in-the-middle changes the port, then initiator which is behind NAT wil
use ports from packet and will never reach the responder. This is also a
DoS attack.
Please let me how location of host (behind NAT or not) helps in avoiding
DoS attack ?

Thanks & Regards,
Raj
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Question regarding security considerations with NAT-T scenario in IKEv2

[Raj Singh]

Hi Tero,


On Thu, Jul 30, 2009 at 2:16 PM, Tero Kivinen  wrote:

> Raj Singh writes:
> > 1. Initiator is behind N(P)AT and float the port to (4500, 4500)
> >
> > and send IKE_AUTH  with source port 4500 now N(P)AT changes source port
> > as 1024 but there is a man-in-the-middle who changes the port to other
> > host behind N(P)AT's port say 1025, still IKE_AUTH packet is
> authenticated.
> >
> > The responder establishes the SA with destination port as 1025 instead of
> > 1024 and sends the reply back to destination port 1025, so it will never
> > reach to original initiator . So the IKE SA will does not get established
> > on initiator But there is no mention of this DoS attack in the draft
> > ?
>
> When the initiator does not get packets, it will retrasnmit its packet
> and if the man-in-the-middle attacker is no longer there it will reach
> the other end and has source port of 1024. This will then be
> authenticated retransmission packet for the other end which will then
> retransmit its previous packet to the address where port numbers were
> swapped. As the packet was not new packet it will not update the SA,
> but next packet from the responder will cause it to update the port
> numbers.
>
> If the man-in-the-middle is still there then the attack is still
> ongoing and he can prevent communications between two peers. He does
> not even need to modify the ports, he can simply delete those
> packets...
>


Agree. But draft does NOT mention about this DoS attack in security
considerations.
We'll have a mention of it in draft as the parent SA itself will come UP
with wrong ports.


>
> > 2. The draft says the host that is NOT behind NAT SHOULD send packet to
> > IP address and port from which it received last authenticated packet.
> > A host behind behind a NAT SHOULD NOT do this because it opens a
> > DoS attack.
>
> Yes.
>
> > But how the location of host(Behind NAT or NOT) avoid DoS attack, say
> > when responder is having public IP, send an UDP encapsulated packet, some
> > man-in-the-middle changes the port, then initiator which is behind NAT
> wil
> > use ports from packet and will never reach the responder. This is also a
> > DoS attack.
> > Please let me how location of host (behind NAT or not) helps in avoiding
> > DoS attack ?
>
> If we take the most common case where the initiator / client is behind
> NAT and responder/server is not behind the NAT. Now the
> responder/server has fixed IP address which will NOT change. Thus if
> host which knows that other end is not behind NAT (i.e. initiator /
> client in this case) does not update IP-addresses at all, as it knows
> the other end has fixed IP-address the attacker cannot force both ends
> to change addresses at the same time. If client would take any packet
> and change other ends address to be as claimed in the headers then
> attacker could simply send one packet that would change client's view
> where the server is, and as the client is behind NAT his old NAT
> mapping would get destroyed after a time, and after that server cannot
> communicate to the client anymore at all.


> --
> kivi...@iki.fi
>

Thanks and Regards,
Raj
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #79: Remove CP from Create_Child_SA?

[Raj Singh]

Hi Yaron,

Also, there are use cases when application needs more than 1 IP address for
internal purpose.
With current ikev2bis, this is possible as we can request address after
session establishment using CP[CFG_REQUEST] in  INFORMATIONAL exchange.
If we say that we want to support in ONLY IKE_AUTH.
Are we going to stop supporting CP payload via INFORMATION exchange ?

Thanks & Regards,
Raj

On Wed, Aug 26, 2009 at 2:53 AM, Yaron Sheffer wrote:

>  Yoav:
>
>
>
> Patricia noted in a post to the IPsec mailing list (12/12/2008) that
> section 2.19 says that "request for such a temporary address can be included
> in any request to create a CHILD_SA (including the implicit request in
> message 3) by including a CP payload."
>
> IMO the normal way of doing things is in this message 3, so rather than a
> parenthetical remark, it's really the only one anyone uses.  I don't think
> it makes sense to assign a different IP address for each SA, and I don't
> think anyone actually intended for this to be implied.
>
>
>
> In RFC 4306, section 3.15, one of the attributes that can be sent in the CP
> payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time
> before the client needs to renew the address with the gateway (probably
> renew the lease with a DHCP server). With such an attribute, it made sense
> for the client to renew the address along with rekeying some CHILD_SA.
>
>
>
> In the bis document, we've deprecated this attribute, and it is now marked
> as "RESERVED". Since we've done that, I suggest we remove the CP payload
> from the Create Child SA exchange in appendix A, and reword section 2.19 to
> reflect that requesting an IP address is only acceptable during IKE_AUTH.
>
>
>
>
>
> Everyone, please comment on the above, even if you support Yoav’s proposal.
> This would be a protocol change (even if we don’t understand what the
> current semantics is…), so we shouldn’t do it unless we’re quite sure.
>
>
>
> 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] #79: Remove CP from Create_Child_SA?

[Raj Singh]

Hi Yoav,

These applications are using same IKE SA for allocating IP to the
application specific virtual interfaces, which can be more than one. Let me
know if you further clarification.

Thanks & Regards,
Raj


2009/8/26 Yoav Nir 

> Hi Raj.
> The issue is concerned with Config payload in Child SA only. Config in
> INFORMATIONAL will stay, or at least, there is no current proposal to remove
> it.
>
> It can be useful for querying the application version, which is still a
> defined attribute for CP.
>
> Can you elaborate on the cases where the application needs more than 1 IP
> address?
>
> Yoav
>
> On Aug 26, 2009, at 6:08 AM, Raj Singh wrote:
>
> Hi Yaron,
>
> Also, there are use cases when application needs more than 1 IP address for
> internal purpose.
> With current ikev2bis, this is possible as we can request address after
> session establishment using CP[CFG_REQUEST] in  INFORMATIONAL exchange.
> If we say that we want to support in ONLY IKE_AUTH.
> Are we going to stop supporting CP payload via INFORMATION exchange ?
>
> Thanks & Regards,
> Raj
>
> On Wed, Aug 26, 2009 at 2:53 AM, Yaron Sheffer wrote:
>
>>  Yoav:
>>
>>
>> Patricia noted in a post to the IPsec mailing list (12/12/2008) that
>> section 2.19 says that "request for such a temporary address can be included
>> in any request to create a CHILD_SA (including the implicit request in
>> message 3) by including a CP payload."
>>
>> IMO the normal way of doing things is in this message 3, so rather than a
>> parenthetical remark, it's really the only one anyone uses.  I don't think
>> it makes sense to assign a different IP address for each SA, and I don't
>> think anyone actually intended for this to be implied.
>>
>>
>> In RFC 4306, section 3.15, one of the attributes that can be sent in the
>> CP payload is the INTERNAL_ADDRESS_EXPIRY. That would be the length of time
>> before the client needs to renew the address with the gateway (probably
>> renew the lease with a DHCP server). With such an attribute, it made sense
>> for the client to renew the address along with rekeying some CHILD_SA.
>>
>>
>> In the bis document, we've deprecated this attribute, and it is now marked
>> as "RESERVED". Since we've done that, I suggest we remove the CP payload
>> from the Create Child SA exchange in appendix A, and reword section 2.19 to
>> reflect that requesting an IP address is only acceptable during IKE_AUTH.
>>
>>
>>
>> Everyone, please comment on the above, even if you support Yoav’s
>> proposal. This would be a protocol change (even if we don’t understand what
>> the current semantics is…), so we shouldn’t do it unless we’re quite sure.
>>
>>
>> Thanks,
>>
>> Yaron
>>
>
>
>
> Email secured by Check Point
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] SCTP Multihoming with IPSec (RFC 3554)

[Raj Singh]

Hi Bhasker,

This document will help you:
http://www.ipsec-howto.org/ipsec-howto.pdf
*It has sample configs for racoon.

*Thanks & Regards,
Raj



On Thu, Aug 27, 2009 at 6:53 PM, Bhaskar Dutta  wrote:

> On Thu, Aug 27, 2009 at 5:43 PM, Tero Kivinen  wrote:
> >
> > Bhaskar Dutta writes:
> > > Does any IPSec implementation support RFC 3554 (On the Use of Stream
> Control
> > > Transmission Protocol (SCTP) with IPsec)?
> >
> > Yes. Altough I do not know if it has been really tested (mostly just
> > using sctp_test and single pair of ip-addresses).
> >
> > > I am working on SCTP over IPSec (linux 2.6.27) and in case of
> multihoming
> > > unless
> > > RFC 3554 is supported I will need to configure 2 * n * m Security
> > > Associations.
> >
> > With IKEv2 you should just create one SA having multiple source and
> > destination addresses. Then if more addresses are later added you need
> > to create new SA with all of the addresses (or just new addresses).
> > --
> > kivi...@iki.fi
>
> Thanks a lot!
>
> I looked up for examples on setting up sainfo entries in racoon's
> remote.conf with
>  multiple source/destination addresses but the man pages or searching the
> web
> did not lead to anything. Couldnt even find any examples with multiple
> entries in sainfo.
>
> Do you have any idea on how to write the sainfo entries in remote.conf
> and spdadd entries
> in setkey.conf that will work with multiple source/dest addresses?
>
> I did write to the ipsec-tools-users list but no luck yet.
>
> Thanks,
> Bhaskar
> ___
> 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] Fw: Issue #26: Missing treatment of error cases

[Raj Singh]

Hi Keith,

It has been already discussed on the list that each exchange has some
mandatory payload types.
Firstly, the exchange packet should be checked that it contains all
mandatory payload for that exchnage
then it should check each payload before actually processing the packet.

In your example of is because of SA2, TSi or TSr, then IKE SA should be
processed and INVALID_SYNTAX notify should be send.

Thanks & Regards,
Raj

On Sat, Sep 5, 2009 at 12:54 AM, Keith Welter  wrote:

>
> > Re: [IPsec] Fw:  Issue #26: Missing treatment of error cases
> >
> > Then I should have explained better.
> >
> > If an initiator sees an error in the response, the exchange is already
> over, so the
> > only way it can notify the responder of the error, is to create a new
> INFORMATIONAL
> > exchange with an error notification.
> >
> > All the text here discusses the one INFORMATIONAL exchange that
> immediately follows
> > the IKE_AUTH exchange. If that contains an INVALID_SYNTAX, it relates to
> the
> > response to the IKE_AUTH exchange, and it means that the creation of the
> IKE SA failed.
> In this case, the INVALID_SYNTAX could relate to the SA, TSi or TSr payload
> in the
> IKE_AUTH response which would would mean that creation of the CHILD SA
> failed,
> not the IKE SA.  I think INVALID_SYNTAX is ambiguous here without an
> explicit delete
> payload for either the IKE SA or the CHILD SA.
>
> >
> > In any other place, such as a CCSA or an INFORMATIONAL,  or in an
> INFORMATIONAL
> > that follows one of those exchanges, an INVALID_SYNTAX just means that
> the previous
> > message was ignored.
> >
> > On Sep 4, 2009, at 7:26 PM, Keith Welter wrote:
> >
> >
> > > >>> In an IKE_AUTH
> > > >>>exchange, or in the subsequent INFORMATIONAL exchnage, only the
> > > >>>following notifications cause the IKE SA to be deleted or not
> > > >>>created, without a DELETE payload:
> > > >>>o  UNSUPPORTED_CRITICAL_PAYLOAD
> > > >>>o  INVALID_SYNTAX
> > > >>>o  AUTHENTICATION_FAILED
> > > >>>
> > > >>>Extension documents may define new error notifications with
> these
> > > >>>semantics, but MUST NOT use them unless the peer is known to
> > > >>>understand them.
> > > >>
> > > >> In subsequent INFORMATIONAL exchanges the
> UNSUPPORTED_CRITICAL_PAYLOAD
> > > >> should not be fatal. It only means that the responder ignored the
> > > >> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That
> does
> > > >> not delete IKE SA.
> > > >>
> > > >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the IKE
>
> > > >> SA as IKE SA is not yet ready.
> > > >
> > > >That's what I meant. I will clarify this.
> > > I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted
> either.
> > Actually, my last statement was overly simplistic.  I should have said
> that
> > there is at least one case when I would not expect INVALID_SYNTAX to
> cause
> > the IKE SA to be deleted; specifically, when it is included in a
> > CREATE_CHILD_SA exchange.  However, I wonder if it is sufficient for an
> > INVALID_SYNTAX in an INFORMATIONAL exchange to cause an IKE SA to be
> deleted
> > without including a delete payload for the IKE SA.  It seems potentially
> > ambiguous what an implementation should do if an INFORMATIONAL message
> > contains only INVALID_SYNTAX whereas the addition of a delete payload for
>
> > the IKE SA makes the situation clear.
> >
> > Keith Welter
> > IBM z/OS Communications Server Developer
> > 1-415-545-2694 (T/L: 473-2694)
> >
> >
> > Scanned by Check Point Total Security Gateway.
> >
> > ___
> > 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
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fw: Issue #26: Missing treatment of error cases

[Raj Singh]

Sorry for typos.
Please find re-phrased sentance below:

In your example, there is error in construction of SA2, TSi or TSr payloads
in IKE_AUTH response.
Which also means either the implementation is not RFC compliant or system in
bad state at responder.
As explained below, in this case mandatory payload check for IKE_AUTH will
pass, but individual payload verification check will fail.
So IKE SA should *NOT* be processed and INVALID_SYNTAX notify should be
send.
The responder which is not RFC compliant will DELETE its IKE SA, after it's
lifetimes expiry or liveness check.

Thanks & Regards,
Raj

On Sun, Sep 6, 2009 at 6:39 AM, Raj Singh  wrote:

> Hi Keith,
>
> It has been already discussed on the list that each exchange has some
> mandatory payload types.
> Firstly, the exchange packet should be checked that it contains all
> mandatory payload for that exchnage
> then it should check each payload before actually processing the packet.
>
> In your example of is because of SA2, TSi or TSr, then IKE SA should be
> processed and INVALID_SYNTAX notify should be send.
>
> Thanks & Regards,
> Raj
>
> On Sat, Sep 5, 2009 at 12:54 AM, Keith Welter  wrote:
>
>>
>> > Re: [IPsec] Fw:  Issue #26: Missing treatment of error cases
>> >
>> > Then I should have explained better.
>> >
>> > If an initiator sees an error in the response, the exchange is already
>> over, so the
>> > only way it can notify the responder of the error, is to create a new
>> INFORMATIONAL
>> > exchange with an error notification.
>> >
>> > All the text here discusses the one INFORMATIONAL exchange that
>> immediately follows
>> > the IKE_AUTH exchange. If that contains an INVALID_SYNTAX, it relates to
>> the
>> > response to the IKE_AUTH exchange, and it means that the creation of the
>> IKE SA failed.
>> In this case, the INVALID_SYNTAX could relate to the SA, TSi or TSr
>> payload in the
>> IKE_AUTH response which would would mean that creation of the CHILD SA
>> failed,
>> not the IKE SA.  I think INVALID_SYNTAX is ambiguous here without an
>> explicit delete
>> payload for either the IKE SA or the CHILD SA.
>>
>> >
>> > In any other place, such as a CCSA or an INFORMATIONAL,  or in an
>> INFORMATIONAL
>> > that follows one of those exchanges, an INVALID_SYNTAX just means that
>> the previous
>> > message was ignored.
>> >
>> > On Sep 4, 2009, at 7:26 PM, Keith Welter wrote:
>> >
>> >
>> > > >>> In an IKE_AUTH
>> > > >>>exchange, or in the subsequent INFORMATIONAL exchnage, only the
>>
>> > > >>>following notifications cause the IKE SA to be deleted or not
>> > > >>>created, without a DELETE payload:
>> > > >>>o  UNSUPPORTED_CRITICAL_PAYLOAD
>> > > >>>o  INVALID_SYNTAX
>> > > >>>o  AUTHENTICATION_FAILED
>> > > >>>
>> > > >>>Extension documents may define new error notifications with
>> these
>> > > >>>semantics, but MUST NOT use them unless the peer is known to
>> > > >>>understand them.
>> > > >>
>> > > >> In subsequent INFORMATIONAL exchanges the
>> UNSUPPORTED_CRITICAL_PAYLOAD
>> > > >> should not be fatal. It only means that the responder ignored the
>> > > >> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That
>> does
>> > > >> not delete IKE SA.
>> > > >>
>> > > >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the
>> IKE
>> > > >> SA as IKE SA is not yet ready.
>> > > >
>> > > >That's what I meant. I will clarify this.
>> > > I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted
>> either.
>> > Actually, my last statement was overly simplistic.  I should have said
>> that
>> > there is at least one case when I would not expect INVALID_SYNTAX to
>> cause
>> > the IKE SA to be deleted; specifically, when it is included in a
>> > CREATE_CHILD_SA exchange.  However, I wonder if it is sufficient for an
>> > INVALID_SYNTAX in an INFORMATIONAL exchange to cause an IKE SA to be
>> deleted
>> > without including a delete payload for the IKE SA.  It seems potentially
>>
>> > ambiguous what an implementation should do if an INFORMATIONAL message
>> > contains only INVALID_SYNTAX whereas the addition of a delete payload
>> for
>> > the IKE SA makes the situation clear.
>> >
>> > Keith Welter
>> > IBM z/OS Communications Server Developer
>> > 1-415-545-2694 (T/L: 473-2694)
>> >
>> >
>> > Scanned by Check Point Total Security Gateway.
>> >
>> > ___
>> > 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
>>
>>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Populating ID_DER_ASN1_DN

[Raj Singh]

Hi David,

On Thu, Sep 17, 2009 at 8:03 AM, David Wierbowski wrote:

> Section 3.1.5 of RFC 4945 states that when generating an ID type of
> ID_DER_ASN1_DN that "implementations MUST populate the contents of ID with
> the Subject field from the end-entity certificate, and MUST do so such that
> a binary comparison of the two will succeed." Section 3.1.5 is specific to
> IKEv1. There is no such requirement listed in Section 4 which is applicable
> to IKEv2.
>
> What is the purpose of this requirement and why is it only applicable to
> IKEv1?
>
> I believe in the past it has been said that the requirement exists because
> smaller devices may not be capable of performing DN matching. If that's the
> case it seems the issue would be applicable to IKEv2 as well.
>
> Section Section 3.1.5 also states, "Regarding SPD matching, implementations
> MUST be able to perform matching based on a bitwise comparison of the entire
> DN in ID to its entry in the SPD. However, operational experience has shown
> that using the entire DN in local configuration is difficult, especially in
> large-scale deployments. Therefore, implementations also MUST be able to
> perform SPD matches of any combination of one or more of the C, CN, O, OU
> attributes within Subject DN in the ID to the same in the SPD."
>
> What is the purpose of requiring the ability to match on a bitwise
> comparison of the entire DN if it is also acceptable to match any
> combination of one or more of the C, CN, O, OU attributes? It seems that
> only implementing the second MUST would be sufficient. If the ID matches a
> bitwise comparison of the entire DN it will also match a combination of one
> or more of the C, CN, O, OU attributes.
>
>
> The entire match is required for tighter security and one certificate not
being used by many users (if they have exportable private keys). Normally,
CN contains info which is specific to the certificate users. If we match
only O, OU that will be same for whole organization. In this case User A who
has exportable private key can share it's certificate with User B and
authentication will be successful.

This is just one of case.


> Dave Wierbowski
>
>
>
>
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
Thanks,
Raj
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication

[Raj Singh]

The selection of AAA server will be based on IDi then EAP will happen.
The gateway will get EAP authenticated ID from the AAA server.
If EAP identity is different from IDi and no policy is found for EAP
identity.
The gateway should initiate deletion of the SA.
Also, if policy is found based on EAP identity, but its different from IDi,
EAP identity should be given priority and its attributes should be applied
on that SA.

On Thu, Nov 12, 2009 at 5:01 AM, Tero Kivinen  wrote:

> Yoav Nir writes:
> > Since the gateway acts as a pass-through, the requirement here is
> > more for the client, which is typically more integrated. The client
> > should be prepared to give an identity hint both in IKE and later in
> > the EAP session.
>
> And in that case the identities should really be same, and if they
> differ then the authenticated identity needs to be used for policy
> lookups, meaning that the EAP identity needs to be used. So the
> gateway needs to get that authenticated identity from the AAA server
> so it can do policy lookups based on it.
> --
> kivi...@iki.fi
> ___
> 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] Proposed work item: IKE/IPsec high availability and load sharing - YES

[Raj Singh]

Hi Team,

According to me, High Availability needs protocol level support from IKEv2
due to windowing and sequence numbers in IPsec.
This will enhance performance and avoid proprietary versions of different
vendors. Here we can discuss various problem and solution of IPsec and HA,
which surely needs some attention.
Also, Kalyani presented a solution syncing-up of IKE message id in internal
meeting. That can be a good starting point.
I would like to review and co-author this draft.

Regards,
Raj

On Sun, Nov 29, 2009 at 10:49 PM, Yaron Sheffer wrote:

>  This work item will define the problem statement and requirements for a
> solution that allows interoperable HA/LS device groups. Mixed-vendor
> clusters are specifically out of scope; but single-vendor clusters should be
> fully interoperable with other vendors’ devices or clusters. The main
> challenge is to overcome the strict use of sequence numbers in both IPsec
> and IKE, in HA and LS scenarios. Following the Hiroshima discussion, the WI
> is initially focused on defining the problem, rather than a particular
> solution.
>
>
>
> Proposed starting point:
> http://tools.ietf.org/id/draft-nir-ipsecme-ipsecha-00.txt.
>
>
>
> Please reply to the list:
>
>
>
> - If this proposal is accepted as a WG work item, are you committing to
> review multiple versions of the draft?
>
> - Are you willing to contribute text to the draft?
>
> - Would you like to co-author it?
>
>
>
> Please also reply to the list if:
>
>
>
> - You believe this is NOT a reasonable activity for the WG to spend time
> on.
>
>
>
> If this is the case, please explain your position. Do not explore the fine
> technical details (which will change anyway, once the WG gets hold of the
> draft); instead explain why this is uninteresting for the WG or for the
> industry at large. Also, please mark the title clearly (e.g. "DES40-export
> in IPsec - NO!").
>
> ___
> 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] Proposed work item: Failure detection in IKEv2 - YES

[Raj Singh]

Hi Team,

According to me, we need to support this draft as WG item as it appears to
enhance the failure detection time.
Currently, there are many scenarios, in which we detect and delete stale SA
only by max. re-transmits.
I would like to review this draft.

Regards,
Raj

2009/11/29 Yaron Sheffer 

> This work item proposes an IKEv2 extension to allow an IKE peer to quickly
> and securely detect that its opposite peer has lost state. This is claimed
> to be quicker than the current method, which is based on time outs.
>
> Proposed starting point: http://tools.ietf.org/id/draft-nir-ike-qcd-05.txtor
> http://tools.ietf.org/html/draft-detienne-ikev2-recovery-03.
>
> Please reply to the list:
>
> - If this proposal is accepted as a WG work item, are you committing to
> review multiple versions of the draft?
> - Are you willing to contribute text to the draft?
> - Would you like to co-author it?
>
> Please also reply to the list if:
>
> - You believe this is NOT a reasonable activity for the WG to spend time
> on.
>
> If this is the case, please explain your position. Do not explore the fine
> technical details (which will change anyway, once the WG gets hold of the
> draft); instead explain why this is uninteresting for the WG or for the
> industry at large. Also, please mark the title clearly (e.g. "DES40-export
> in IPsec - NO!").
> ___
> 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] Proposed work item: Childless IKE SA

[Raj Singh]

Hi Alper,


On Fri, Dec 18, 2009 at 5:19 AM, Alper Yegin  wrote:

> Hi,
>
> I'm hoping by now it is understood that "childless IKE SA" is just a
> technical detail of what is really on the table. The proposal on the table
> is "designing a network access authentication protocol based on IKEv2".
> That's what this WG and IETF should be discussing.
>
> Having multiple solutions for the very same problem space creates
> interoperability problem.  If IETF has defined a protocol for a given
> problem, and if some other people come along and ask another solution be
> standardized for the very same problem, IETF needs a justification.
> Otherwise, we end up working "against" interoperability, not "for".
>
> The only justification I'm hearing is "we don't want to use PANA because it
> is not implemented in my stack." This is an extremely poor justification.
> One can say it for any new protocol, and choose to hack up whatever he/she
> has. How can growing PANA out of IKEv2 be any better than using PANA.
>
> IKEv2 is defined and used for creating IPsec SAs.


IKE is Internet Key Exchange protocol NOT IPsec Key Exchange protocol.
IKEv2 is not just a mean of exchanging keys but its a full package.
This package provides mutual authentication, keys and readiness to secure
data as needed.
The main motivation for this draft is Remote Access VPN scenario.

Yeah, it needs to perform
> peer authentication, but that's for creating securing the IPsec SA
> creation.
> There are many other protocols that authenticate the peers for the sake of
> securely performing their own dedicated objectives. E.g., Mobile IP
> authenticates MN and HA for securely creating binding caches; RFC 3118
> authenticates DHCP client and DHCP server for secure host configuration;
> etc. etc. Taking the peer authentication parts of these protocols and use
> it
> for totally different purposes is not right.
>
> > I don't see why we couldn't let IKEv2 have a go at displacing PANA in the
> marketplace.
>
> Few folks want to twist IKEv2 into network access authentication protocol
> (this proposal).
> Few other folks want to twist DHCP into network access authentication
> protocol (EAP-over-DHCP proposal).
> Few other folks want to twist HTTP into network access authentication
> protocol (EAP-over-HTTP proposal).
>
> They all have the exact same (poor) justification: We need EAP-over-Foo
> because we already have Foo.
>
> The above list is what is already being entertained here and there. The
> list
> is very likely to grow.
>
> How can that not be a problem if all were getting standardized (for the
> sake
> of argument, let's forget about the technical brokenness of the last two
> proposals). Every one of them think they were saving by implementing "one",
> but in fact all are getting implemented eventually. Each access
> authentication specific feature needs to be reproduced on each such
> protocol. A multi-mode terminal (host) and NAS need to implement all.
>
>
> > What's really not desirable is non-interoperability, and that, I believe,
> we can achieve by making PANA the required to implement network access
> protocol.
>
> "We" (IETF) do not and cannot make PANA "required to implement" network
> access authentication protocol. Other SDOs/platforms make such mandates.
> So,
> I don't think saying "no" to redundant solutions is a bad thing that that
> way.
>
> If someone is truly hung up on using IKEv2 purely for network access
> authentication, why can't they already do so? So what if it creates an
> IPsec
> SA. Just don't use it.
>
> > Suppose you want a combination of "peer authentication only" for some
> > traffic and "peer authentication + ESP/AH" for other kinds of traffic
> > (think of this as differentiated services).  Then to use PANA for one
> > and IPsec for the other seems silly.
>
> Is this a real scenario? This is not the scenario Hui brought up. He's
> talking about Femto AP connecting to femto access network via WAN; in one
> case (a) WAN is already secured (e.g., via physical security) and he does
> not need to use IPsec at all; in the other case (b) WAN is open Internet
> and
> ne needs to use IPsec. In both cases, he needs to authenticate the Femto AP
> and he wants to use IKEv2 for that. And I say use PANA instead.
>
> So, PANA-based solution becomes this:
> For case (a): Use PANA for Femto AP authentication. That's all you need.
> For case (b): Use PANA for Femto AP authentication, use IKEv2 for setting
> up
> IPsec SA.
>
>
>
> 
>
> I'm not disputing doability of this proposal. See, an even worse example is
> 3GPP2 using Mobile IPv4 authentication for L3 network access authentication
> between the MS (MN) and PDSN (FA). I guess we are lucky that they didn't
> come to IETF for tweaking RFC 4004 for that (they could get good number of
> support, if we were going with that indication only). This can also made to
> work, but IMHO there is much bigger harm than benefit in this case.
>
> Alper
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 

Re: [IPsec] Some IPSEC/IKE NAT Issues

[Raj Singh]

Hi Syed,


On Mon, Dec 28, 2009 at 5:51 PM, Syed Ajim Hussain wrote:

>
>
> Hi All
>I have some doubt about NAT With IPSEC/IKE ,
>
>  Example Take a Topology :
>
>  IKE_PEER1  --- NAT1 NAT2 Server---IKE_PEER3
>  (1.1.1.1)   |  (1.1.1.10)  (2.1.1.1)  (2.1.1.2)   (3.1.1.1)
>  |
>  IKE_PEER2   |
>  (1.1.1.2)
>
>  IKE_PEER1 and  IKE_PEER2 ,  behind Same NAT Device NAT1 ,  Want to
>  Establish IPSEC Tunnel with   IKE_PEER3, which is Behind a NAT Server (
>  Service Running Behind a NAT).
>
>  For IKE_PEER1, IKE_PEER2, NAT2 Server Address (2.1.1.2) is the Peer
>  Address, Since IKE_PEE3 running behind a NAT Server.
>
> Questions1:
>
>  1. For IKE_PEER3, 2.1.1.1   is the Peer Address for both IKE_PEER1 &
>IKE_PEER2. If IKE ID Type is IP Address then, how IKE SA can be
>Established, between IKE_PEER1& IKE_PEER3 and IKE_PEER2 & IKE_PEER3,
>
> Even though IKE_PEER3 sees same IP address for IKE_PEER1 and IKE_PEER2, the
source port will be different to distinguish the connections.

2.   If ID Type is based on Name (FQDN), Say IPSEC Tunnel is
> Established Between IKE_PEER1 & IKE_PEER3.  If IPSEC SA Mode is
> Tunnel,  Now Inner IP Header may have Destination IP Address as NAT2
> Server's Address that is (2.1.1.2).  This Original IP Packet will be a
> payload of IPSEC Encapsulated  packet.
>
> Since NAT2 Server, will Change only Outer IP Header Destination
> Address, to Forward the packet to IKE_PEER3.
>
> Now in   IKE_PEER3 after IPSEC Decapsulation, original Packet will
> Have 2.1.1.2 (NAT Server's Address) as Destination Address.  Now How
> This packet can be processed in IKE_PEER3.
>
> The IKE_PEER3 can forward these packets to NAT device as they are not
destined to it.

> Does tunnel Mode Can not be supported in such Topology??
>
> If RFC is not clear about such Solution, then we can have one RFC
> To solve this scenario.
>
>
> With Regards
> Syed Ajim
>
>
>
> 
> This e-mail and attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including,
> but not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by
> phone or email immediately and delete it!
>
> ***
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

Regards,
Raj
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Review of section 1 of the draft-ietf-ipsecme-ikev2bis-06.txt

[Raj Singh]

*
*

*
*

Section 1.2.  The Initial Exchanges

   Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
   exchanges (known in IKEv1 as Phase 1).  These initial exchanges
   normally consist of four messages, though in some scenarios that
   number can grow.  All communications using IKE consist of request/
   response pairs.  We'll describe the base exchange first, followed by
   variations.  The first pair of messages (IKE_SA_INIT) negotiate
   cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
   exchange [DH
].


It would be better to say


   Communication using *IKEv2* always begins with IKE_SA_INIT and IKE_AUTH
   exchanges (known in IKEv1 as Phase 1).  These initial exchanges
   normally consist of four messages, though in some scenarios that
   number can grow.  All communications using IKE consist of request/
   response pairs.  We'll describe the base exchange first, followed by
   variations.  The first pair of messages (IKE_SA_INIT) negotiate
   cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
   exchange [DH
].


Even though IKE has been used before this section where it is meant as
IKEv2. So, also we can say like. "IKE and IKEv2 has been used
interchangeably".

But some place IKE is refer'd as generic protocol. So, mentioning IKE,
IKEv1 and IKEv2 need to be done.



Thanks & Regards,

Raj


On Fri, Jan 15, 2010 at 2:01 PM, Tero Kivinen  wrote:

> Scott C Moonen writes:
> > > Section 1.4 says that
> > >
> > >INFORMATIONAL exchanges MUST ONLY occur
> > >after the initial exchanges and are cryptographically protected with
> > >the negotiated keys.
> > >
> > > This does not match the 1.5 which says we can send INFORMATIONAL
> > > exchanges also outside the IKE SA.
> >
> > I think that section 1.5 is pretty careful to distinguish between
> > informational messages (sent outside the IKE SA) and informational
> > exchanges (which occur only within the context of an IKE SA).  I'm
> > inclined to keep the Section 1.4 text as it is.  If you prefer, though,
> > I'd be ok with clarifying Section 1.4 to say "INFORMATIONAL exchanges (to
> > be distinguished from INFORMATIONAL messages sent outside the context of
> > an IKE SA) . . ."
>
> That change looks even better than my proposed one...
> --
> kivi...@iki.fi
> ___
> 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] Issue #156: SHOULD generate and accept which types?

[Raj Singh]

Hi Team,

I agree with Tero explanation and Valery objection as well.
There is discrepancy between 3.5 and 4.
1. Section 4 mandates certificates but section 3.5 doesn't.
2. Its seen in practice that some implementation uses IP addresses as
default ID even though they are
using certificate based authentication or they are behind NAT.
This should is NO use as explained by Tero and should be discouraged in
draft and proper ID types i.e. ID_DER_ASN1_DN for
certificate based authentication should be encouraged.

Regards,
Raj


On Fri, Jan 22, 2010 at 3:24 PM, Tero Kivinen  wrote:

> Paul Hoffman writes:
> > At 9:17 PM -0500 1/21/10,  wrote:
> > >Paul,
> > >
> > >> What does "Implementations SHOULD be capable of generating and
> > >accepting all of these types" mean?
> > >
> > >It's hair-splitting time ...
> > >
> > >> To assure maximum interoperability, implementations MUST be
> > >configurable to send at least one of
> > >> ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be
> > >configurable to accept all of these
> > >> types.
> > >
> > >Short version: MUST be able to send at least *1*, accept all *4*.
> > >
> > >> Implementations SHOULD be capable of generating and accepting all of
> > >these types.
> > >
> > >Short version: In addition, SHOULD be able to send all *4*.
> > >
> > >The SHOULD for "accepting" is redundant with the previous MUST, but the
> > >SHOULD for "generating" is broader.
> > >
> > >[... snip ...]
> > >
> > >> If it means all the listed types, the sentence should be changed to
> > >"Implementations SHOULD
> > >> also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and
> > >ID_DER_ASN1_GN."
> > >
> > >Which I think amounts to a SHOULD for certificate support.  Is there a
> > >good reason to go there?
> >
> > This interpretation is quite surprising to me (but I am surprised
> > often these days...). What do others think?
>
> I interpreted it so that MUST be able to send one, accept all four
> and SHOULD be able to send all four.
>
> Note, also that Section 4 also lists in its conformance list that all
> implementations MUST be able to be configured to accept:
> --
>For an implementation to be called conforming to this specification,
>   it MUST be possible to configure it to accept the following:
>
>   o  PKIX Certificates containing and signed by RSA keys of size 1024
>  or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
>  ID_RFC822_ADDR, or ID_DER_ASN1_DN.
>
>   o  Shared key authentication where the ID passed is any of ID_KEY_ID,
>  ID_FQDN, or ID_RFC822_ADDR.
>
>   o  Authentication where the responder is authenticated using PKIX
>  Certificates and the initiator is authenticated using shared key
>  authentication.
> --
>
> I.e. that adds ID_DER_ASN1_DN for certificates, and does not list
> ID_IPV*_ADDR at all.
>
> I.e. even when ID_IPV4_ADDR is mandatory to be implement, that does
> not need to be one of the configurations that is required from
> implementation (which is ok, as if you make implementation which is
> always behind NAT, then IP-address is not something you want to allow
> to be configured as ID).
>
> So Certificate support is already MUST, Shared key authentication is
> MUST. ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR are MUST for accept for both
> authentication, ands ID_DER_ASN1_DN is MUST for accept for certificate
> authentication.
>
> The section 4 can also be understood that sending all of the ID
> formats is also required, as the text says "ID passed is any of ..."
> which would indicate that it requires also sending those ID types.
>
> These requirements are not required to be same, as the other covers
> the ID payload support, and the other covers the how the whole system
> is configured and used.
> --
> kivi...@iki.fi
> ___
> 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] Issue #156: SHOULD generate and accept which types?

[Raj Singh]

On Fri, Jan 22, 2010 at 5:15 PM, Tero Kivinen  wrote:
>
> Raj Singh writes:
> > I agree with Tero explanation and Valery objection as well.
> > There is discrepancy between 3.5 and 4.
>
> Not really. Not all requirements needs to be in one place. One place
> can say that XXX is required and another place can say that also YYY
> is required, but only if doing ZZZ.
>
> > 1. Section 4 mandates certificates but section 3.5 doesn't.
>
> Section 3.5 does not and should not say anything about certificates,
> it just lists which ID types there are which of them needs to be
> supported.

Agree. But it should mandate ID_DER_ASN1_DN which it doesn't.
>
> > 2. Its seen in practice that some implementation uses IP addresses as
> > default ID even though they are
> > using certificate based authentication or they are behind NAT.
>
> And this is allowed and section 3.5 sees that ID_IPV4_ADDR support is
> madantory (and ID_IPV6_ADDR is mandatory for IPv6-capable
> implementations).
>
> Nothing in the section 4 claims otherwise, so they are still mandatory
> to accept from the other end.
>
> On the other hand section 4 does not require ID_IPV*_ADDR address to
> be one of those which can be configured to be used and it adds one
> more requirement compared to what section 3.5 said i.e. it says that
> if PKIX certifiates are used then implementations need to also needto
> be able to use ID_DER_ASN1_DN.

To put my point simply:
1. Section 3.5:
-
   Two implementations will interoperate only if each can generate a
   type of ID acceptable to the other.  To assure maximum
   interoperability, implementations MUST be configurable to send at
   least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
   MUST be configurable to accept all of these types.
   ---

   Here we are mandating that an implementation MUST be able to configure to
   accept 4 ID types with types without any mention of ID_DER_ASN1_DN.

   Section 4:
   ---
   For an implementation to be called conforming to this specification,
   it MUST be possible to configure it to accept the following:

   - PKIX Certificates containing and signed by RSA keys of size 1024
  or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
  ID_RFC822_ADDR, or ID_DER_ASN1_DN.
   

  Here we are also mandating than an implementaion MUST be able to configure
  to accept  ID_DER_ASN1_DN.

This is what i was referring to that there is some discrepancy between
3.5 and 4.

As PKIX support is MUST for implementations of ikev2bis, we can't say that
we are adding one more requirement if PKIX is supported.
>
> > This should is NO use as explained by Tero and should be discouraged in
> > draft and proper ID types i.e. ID_DER_ASN1_DN for
> > certificate based authentication should be encouraged.
> --
> kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Detecting NAT rebooting

[Raj Singh]

Hi Paul,

A system can detect NAT mapping removal from CHANGED source port from
authenticated IKE PACKET.
A system can detect NAT mapping removal from CHANGED source port  of
UDP encapsulated packet from authenticated IPsec PACKET.
Also, system knows in process of NAT detection, where it is behind NAT
or Pee is behind NAT or Both are behind NAT.

Thanks,
Raj

On Tue, Feb 2, 2010 at 9:14 AM, Paul Hoffman  wrote:
> Greetings again. ikev2bis 2.23 says:
>
>   o  There are cases where a NAT box decides to remove mappings that
>      are still alive (for example, the keepalive interval is too long,
>      or the NAT box is rebooted).  To recover in these cases, hosts
>      that do not support other methods of recovery such as MOBIKE
>      [MOBIKE], and that are not behind a NAT, SHOULD send all packets
>      (including retransmission packets) to the IP address and port from
>      the last valid authenticated packet from the other end (that is,
>      they should dynamically update the address).  A host behind a NAT
>      SHOULD NOT do this because it opens a possible denial of service
>      attack.  . . .
>
> How does a system on either side of the NAT detect this mapping removal?
>
> --Paul Hoffman, Director
> --VPN Consortium
> ___
> 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] Issue #173: Trigger packets should not be required

[Raj Singh]

I support this change.

On Wed, Feb 3, 2010 at 4:22 AM, Dan McDonald  wrote:
> On Tue, Feb 02, 2010 at 02:49:11PM -0800, Paul Hoffman wrote:
>> In a few places in the new section 2.23.1 in IKEv2bis, it says that one
>> must have a trigger packet when starting negotiation. This assumption
>> should be removed so as not to cause new requirements in IKEv2bis: there is
>> no requirement for trigger packets in RFC 4306 or in the rest of IKEv2bis.
>
> BTW, this change makes a path to no-child-SA AUTH exchanges simpler.  It's
> much simpler to have a no-child-SA creation of an IKE SA when you aren't
> initiating in the service of a triggering packet.
>
>> - "When the client starts creating the IKEv2 SA and Child SA for sending
>> traffic to the server, it has a triggering packet with source IP address of
>> IP1, and a destination IP address of IPN2" should be changed to "...it may
>> have a triggering packet...".
>
> This new text is fine.
>
>> - "The first traffic selector of TSi and TSr SHOULD have very specific
>> traffic selectors including protocol and port numbers from the packet
>> triggering the request" should be changed to "...SHOULD have very specific
>> traffic selectors including protocol and port numbers, such as from the
>> packet...".
>
> As is this new text.
>
> Dan
> ___
> 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

[IPsec] Fwd: Issue : Regarding EAP identity

[Raj Singh]

Hi Paul, Ticket Issue#174 opened for it. Regards, Raj

-- Forwarded message --
From: Paul Hoffman 
Date: Wed, Feb 3, 2010 at 9:41 AM
Subject: Re: Issue : Regarding EAP identity
To: Raj Singh 
Cc: Yaron Sheffer 


 At 9:09 AM +0530 2/3/10, Raj Singh wrote:

Hi Paul,

In ikev2bis07
  -* ikev2-bis-07 section 2.16, last
paragraph*---
 When the initiator authentication uses EAP, it is possible that the
 contents of the IDi payload is used only for AAA routing purposes and
 selecting which EAP method to use.  This value may be different from
 the identity authenticated by the EAP method.  It is important that
 policy lookups and access control decisions use the actual
 authenticated identity.  Often the EAP server is implemented in a
 separate AAA server that communicates with the IKEv2 responder.  *In
 this case, the authenticated identity has to be sent from the AAA
 server to the IKEv2 responder.*
-
--
It says the autheticated EAP identity "has to" be send from AAA server, our
iterpretation is "has to" is obvious MUST.


I believe that is correct.

If AAA doesn't send the authenticated EAP identity, what should be
the behavior?


I would assume "everything stops"

Also, what if AAA server EAP server is not AAA server?


Good question.

Can i open a ticket for it?


Yes, please!

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: Issue : Regarding EAP identity

[Raj Singh]

Hi Yaron,

The question is more towards when EAP identity is needed and
is different from IDi. But AAA server doesn't send it, we will fail.
But draft doesn't have any say for this scenario. So it becomes mandatory
for AAA server to send identity.

Regards,
Raj

On Wed, Feb 3, 2010 at 11:22 AM, Yaron Sheffer wrote:

>  The authenticated identity needs to be sent by the AAA server to the IKE
> responder in some cases only. For example, in EAP-SIM/AKA people often use
> “temporary” (anonymized) identities in IDi. But in other cases, like
> EAP-MSCHAPv2 or (God forbid!) EAP-GTC, there’s no need for a separate
> “authenticated identity”. In these cases the IKE responder should simply use
> the original IDi for policy lookup.
>
>
>
> Thanks,
>
> Yaron
>
>
>
> *From:* ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] *On Behalf
> Of *Raj Singh
> *Sent:* Wednesday, February 03, 2010 7:45
> *To:* ipsec
> *Subject:* [IPsec] Fwd: Issue : Regarding EAP identity
>
>
>
> Hi Paul, Ticket Issue#174 opened for it. Regards, Raj
>
> -- Forwarded message --
> From: *Paul Hoffman* 
> Date: Wed, Feb 3, 2010 at 9:41 AM
> Subject: Re: Issue : Regarding EAP identity
> To: Raj Singh 
> Cc: Yaron Sheffer 
>
>   At 9:09 AM +0530 2/3/10, Raj Singh wrote:
>
> Hi Paul,
>
> In ikev2bis07
>   -* ikev2-bis-07 section 2.16, last 
> paragraph*---
>  When the initiator authentication uses EAP, it is possible that the
>  contents of the IDi payload is used only for AAA routing purposes and
>  selecting which EAP method to use.  This value may be different from
>  the identity authenticated by the EAP method.  It is important that
>  policy lookups and access control decisions use the actual
>  authenticated identity.  Often the EAP server is implemented in a
>  separate AAA server that communicates with the IKEv2 responder.  *In
>  this case, the authenticated identity has to be sent from the AAA
>  server to the IKEv2 responder.*
>
> ---
> It says the autheticated EAP identity "has to" be send from AAA server, our
> iterpretation is "has to" is obvious MUST.
>
>
> I believe that is correct.
>
> If AAA doesn't send the authenticated EAP identity, what should be
> the behavior?
>
>
>
> I would assume "everything stops"
>
>
>
> Also, what if AAA server EAP server is not AAA server?
>
>
>
> Good question.
>
> Can i open a ticket for it?
>
>
>
> Yes, please!
>
>
> --Paul Hoffman, Director
> --VPN Consortium
>
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: Issue : Regarding EAP identity

[Raj Singh]

Hi Yoav,

According to RFC-3579 [Appendix-A] RADIUS (Remote Authentication Dial In
User Service) Support For Extensible Authentication Protocol (EAP) shows
that NAS (IKEv2 Gateway) sends an EAP-Request/Identity as the initial packet
to IKEv2 initiator. Here IKEv2 will come to know EAP identity and apply
policy based on authenticated identity.

We can add text at end of section 2.16 that if authenticated identity is not
sent by AAA server to IKEv2 responder, the IKEv2 responder can begin EAP
authentication by sending EAP-Request/Identity as the initial packet to
IKEv2 initiator.

Regards,
Raj

2010/2/4 Yoav Nir 

> The IKEv2 responder enforces policy, so it has to know the identity, both
> for enforcement and auditing. Suppose y...@checkpoint.com is allowed to
> access server X, while alper.ye...@yegin.org is not, then the IKEv2
> responder needs to both block your attempts to access server X (perhaps by
> failing the CREATE_CHILD_SA exchange), and to log that you tried this.
>
> If auditing is not required, it's possible to work with some kind of
> pseudo-identity, but in that case, for the IKEv2 responder, this is the
> authenticated identity.
>
> Unless there is a single policy for all authenticated users, you do need
> the user identity.
>
> -Original Message-
> From: Alper Yegin [mailto:alper.ye...@yegin.org]
> Sent: Thursday, February 04, 2010 3:40 PM
> To: Yoav Nir; 'Raj Singh'; Yaron Sheffer
> Cc: 'ipsec'
> Subject: RE: [IPsec] Fwd: Issue : Regarding EAP identity
>
> Hello,
>
> Why would the IKEv2 responder need to know the real identity?
> There can be privacy reasons for hiding it from any entity other than the
> AAA/authentication server.
>
> I'm thinking that mandating AAA server to reveal that value is not
> necessary
> and also problematic.
>
> Alper
>
>
>
>
> > -Original Message-
> > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> > Of Yoav Nir
> > Sent: Wednesday, February 03, 2010 10:43 AM
> > To: 'Raj Singh'; Yaron Sheffer
> > Cc: ipsec
> > Subject: Re: [IPsec] Fwd: Issue : Regarding EAP identity
> >
> > Hi Raj
> >
> > I don’t think we can specify MUST requirements for the AAA servers,
> > because we’re not specifying RADIUS or DIAMETER here.
> >
> > For example in RADIUS, the VPN gateway sends an Access-Request to the
> > server, which contains the user-name, presumably the same user-name
> > from the IDi payload.
> >
> > If the server authenticates the user successfully, and has not sent an
> > user-name attribute, then I guess we can assume that it has
> > authenticated the identity sent in the access-request payload (= the
> > identity in the IDi payload). For example, if I pass the identifier
> > “ynir” (which is unique at my company) or “y...@checkpoint.com”, which
> > is globally unique, this is good enough for policy updates, even if the
> > EAP server did not send another identity.
> >
> > Of course, in some cases the IDi could be an anonymized identity, and
> > then if the server doesn’t give us a real identity, then something is
> > wrong. But this distinction is a matter for local policy, which I don’t
> > think we can specify in ikev2bis. In any case, policy lookups have to
> > be done using the authenticated identity, either the one in IDi or the
> > one supplied by the AAA server. I think the line “It is important that
> > policy lookups and access control decisions use the actual
> > authenticated identity.” conveys that.
> >
> >
> > 
> > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> > Of Raj Singh
> > Sent: Wednesday, February 03, 2010 8:22 AM
> > To: Yaron Sheffer
> > Cc: ipsec
> > Subject: Re: [IPsec] Fwd: Issue : Regarding EAP identity
> >
> > Hi Yaron,
> >
> > The question is more towards when EAP identity is needed and
> > is different from IDi. But AAA server doesn't send it, we will fail.
> > But draft doesn't have any say for this scenario. So it becomes
> > mandatory for AAA server to send identity.
> >
> > Regards,
> > Raj
> > On Wed, Feb 3, 2010 at 11:22 AM, Yaron Sheffer 
> > wrote:
> > The authenticated identity needs to be sent by the AAA server to the
> > IKE responder in some cases only. For example, in EAP-SIM/AKA people
> > often use “temporary” (anonymized) identities in IDi. But in other
> > cases, like EAP-MSCHAPv2 or (God forbid!) EAP-GTC, there’s no need for
> > a separate “authenticated identity”. In these cases the IKE responder
> >

Re: [IPsec] Fwd: Issue : Regarding EAP identity

[Raj Singh]

Hi Dan,


On Fri, Feb 5, 2010 at 2:47 AM, Dan Harkins  wrote:

>
>  Hi Raj,
>
>  RFC 3748 (the RFC defining EAP) says:
>
>  The Identity Response may not be the appropriate
>  identity for the method; it may have been truncated or obfuscated
>  so as to provide privacy, or it may have been decorated for
>  routing purposes.
>
> In other words, the identity the IKEv2 gateway receives is worthless
> for authentication purposes and authentication is what IKE does. That
> identity is just to decide what EAP method to use with the peer. It is
> not an "authenticated identity" as you suggest. RFC 3748 further
> recommends:
>
>  [F]or an EAP method to include an identity exchange that supports
>  per-packet authentication, integrity and replay protection, and
>  confidentiality.
>

That sounds quite reasonable and suggests each EAP method SHOULD have
identity exchange for EAP authentication with IKEv2. Current draft doesn't
say
like that. That's my concern.


> So the identity that is used for _authentication of the peer_ is something
> that is just passed through the IKEv2 gateway and may even be encrypted by
> a key that the IKEv2 gateway does not have access to.
>
>  Imagine the next time some guard at a building or in an airport says,
> "let me see your ID please" when you attempt to gain entry and you say,
> "sorry you're not in a position to see that but our shared friend here
> can vouch for me." How do you think that's gonna fly? Not too well, I'd
> imagine.
>
> On a lighter note: It will be like flying without passport. :-)

With Regards,
Raj

>  regards,
>
>  Dan.
>
> On Thu, February 4, 2010 8:56 am, Raj Singh wrote:
> > Hi Yoav,
> >
> > According to RFC-3579 [Appendix-A] RADIUS (Remote Authentication Dial In
> > User Service) Support For Extensible Authentication Protocol (EAP) shows
> > that NAS (IKEv2 Gateway) sends an EAP-Request/Identity as the initial
> > packet
> > to IKEv2 initiator. Here IKEv2 will come to know EAP identity and apply
> > policy based on authenticated identity.
> >
> > We can add text at end of section 2.16 that if authenticated identity is
> > not
> > sent by AAA server to IKEv2 responder, the IKEv2 responder can begin EAP
> > authentication by sending EAP-Request/Identity as the initial packet to
> > IKEv2 initiator.
> >
> > Regards,
> > Raj
> >
> > 2010/2/4 Yoav Nir 
> >
> >> The IKEv2 responder enforces policy, so it has to know the identity,
> >> both
> >> for enforcement and auditing. Suppose y...@checkpoint.com is allowed to
> >> access server X, while alper.ye...@yegin.org is not, then the IKEv2
> >> responder needs to both block your attempts to access server X (perhaps
> >> by
> >> failing the CREATE_CHILD_SA exchange), and to log that you tried this.
> >>
> >> If auditing is not required, it's possible to work with some kind of
> >> pseudo-identity, but in that case, for the IKEv2 responder, this is the
> >> authenticated identity.
> >>
> >> Unless there is a single policy for all authenticated users, you do need
> >> the user identity.
> >>
> >> -Original Message-
> >> From: Alper Yegin [mailto:alper.ye...@yegin.org]
> >> Sent: Thursday, February 04, 2010 3:40 PM
> >> To: Yoav Nir; 'Raj Singh'; Yaron Sheffer
> >> Cc: 'ipsec'
> >> Subject: RE: [IPsec] Fwd: Issue : Regarding EAP identity
> >>
> >> Hello,
> >>
> >> Why would the IKEv2 responder need to know the real identity?
> >> There can be privacy reasons for hiding it from any entity other than
> >> the
> >> AAA/authentication server.
> >>
> >> I'm thinking that mandating AAA server to reveal that value is not
> >> necessary
> >> and also problematic.
> >>
> >> Alper
> >>
> >>
> >>
> >>
> >> > -Original Message-
> >> > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On
> Behalf
> >> > Of Yoav Nir
> >> > Sent: Wednesday, February 03, 2010 10:43 AM
> >> > To: 'Raj Singh'; Yaron Sheffer
> >> > Cc: ipsec
> >> > Subject: Re: [IPsec] Fwd: Issue : Regarding EAP identity
> >> >
> >> > Hi Raj
> >> >
> >> > I don’t think we can specify MUST requirements for the AAA servers,
> >> > because we’re not specifying RADIUS or DIAMETER here.
> >> >
> >> >

Re: [IPsec] Issue #175: Better wording for NAT mobility issues

[Raj Singh]

Hi Paul,

One clear change is that updating the address, port info is changed from
authenticated packet
to integrity protected packet.
Does this change is to allow recovery from NAT mapping removal during
establishment of IKEv2 SA
e.g. with EAP authentication, during retransmission of IKE_AUTH exchange ?
If Yes, can we have a explicit say for it?

Regards,
Raj



On Fri, Feb 5, 2010 at 7:15 AM, Paul Hoffman  wrote:

> The last bullet in 2.23 is confusing. A proposed rewrite is:
>
> Old:
>
> There are cases where a NAT box decides to remove mappings that are
> still alive (for example, the keepalive interval is too long, or the
> NAT box is rebooted).  To recover in these cases, hosts that do not
> support other methods of recovery such as MOBIKE [MOBIKE], and that
> are not behind a NAT, SHOULD send all packets (including
> retransmission packets) to the IP address and port from the last
> valid authenticated packet from the other end (that is, they should
> dynamically update the address).  A host behind a NAT SHOULD NOT do
> this because it opens a possible denial of service attack.  Any
> authenticated IKE packet or any authenticated UDP- encapsulated ESP
> packet can be used to detect that the IP address or the port has
> changed.  When IKEv2 is used with MOBIKE, dynamically updating the
> addresses described above interferes with MOBIKE's way of recovering
> from the same situation.  See Section 3.8 of [MOBIKE] for more
> information.
>
> New:
>
> There are cases where a NAT box decides to remove mappings that are
> still alive (for example, the keepalive interval is too long, or the
> NAT box is rebooted). This will be apparent to a host if it receives
> a packet whose integrity protection validates, but has a different
> port, address, or both from the one that was associated with the SA
> in the validated packet. When such a validated packet is found, a
> host that does not support other methods of recovery such as MOBIKE
> [MOBIKE], and that is not behind a NAT, SHOULD send all packets
> (including retransmission packets) to the IP address and port in the
> validated packet, and SHOULD store this as the new address and port
> combination for the SA (that is, they SHOULD dynamically update the
> address). A host behind a NAT SHOULD NOT do this type of dynamic
> address update if a validated packet has different port and/or
> address values because it opens a possible denial of service attack
> (such as allowing an attacker to break the connection with a single
> packet). When IKEv2 is used with MOBIKE, dynamically updating the
> addresses described above interferes with MOBIKE's way of recovering
> from the same situation.  See Section 3.8 of [MOBIKE] for more
> information.
>
> --Paul Hoffman, Director
> --VPN Consortium
> ___
> 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

[IPsec] Clarification needed regarding IRAC requesting an internal address from IRAS.

[Raj Singh]

Hi Team,

When IRAC requests an internal address from IRAS.
Now IRAS gets the address for IRAC and applies some local policies and
fails.
In this case which notify is it should send INTERNAL_ADDRESS_FAILURE or
generic NO_PROPOSAL_CHOSEN?
IKEv2 SA comes up in both cases.

Please provide your views.

Regards,
Raj
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #175: Better wording for NAT mobility issues

[Raj Singh]

2010/2/8 Tero Kivinen 

> Raj Singh writes:
> > One clear change is that updating the address, port info is changed from
> > authenticated packet
> > to integrity protected packet.
>
> In this case that does not really matter.
>
> > Does this change is to allow recovery from NAT mapping removal
> > during establishment of IKEv2 SA e.g. with EAP authentication,
> > during retransmission of IKE_AUTH exchange ? If Yes, can we have a
> > explicit say for it?
>
> This is not necessarely needed, as the IKE_AUTH replies are IKE
> packets, which are always sent back with their addresses reversed,
> thus those replies will go back anyways, and there cannot be any other
> packets (IKE or ESP) before the IKE_AUTH finishes, and that last
> IKE_AUTH packet is already also authenticated (in addition to the
> integrity protected), thus the last IKE_AUTH packet will already cause
> the mappings to be updated.
>
> So either wording is fine. What is not fine is to do the changes if
> the packet is replayed.
>

Suppose responder got IKE_AUTH request (NIP1, NP1), and now mapping got
removed at NAT box.
If responder will send packet to packet to last integrity protected packet
i.e. IKE_AUTH request.
It will send IKE_AUTH packet to (NIP1, NP1), but now NAT mappings are
removed, so it will not reach to the initiator.
If we are using EAP authentication then first IKE_AUTH will not contain AUTH
payload, so its NOT authenticated packet.
Its only integrity protected. Thats was the thought behind the question.


--
> kivi...@iki.fi
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: Issue : Regarding EAP identity

[Raj Singh]

On Wed, Feb 10, 2010 at 3:44 PM, Alper Yegin  wrote:

> Dan,
>
> >   Hi Alper,
> >
> >   In that case there is no standard way for the AAA server to inform
> > the
> > IKEv2 responder of this "policy" that it needs to enforce. So that
> > sounds
> > unworkable.
>
> I guess it can be specified.
>
> >   The IKEv2 responder already has the mechanisms in place to enforce a
> > policy based on the authenticated identity of the IKEv2 initiator. So
> > if
> > EAP is being used then all we need is a way to get that authenticated
> > identity from the AAA server to the IKEv2 responder.
>
> Isn't IDi what IKE deals with?
>
> >   I'm not aware of a document to allows a AAA server to export the
> > authenticated identity to the AAA client (maybe such an attribute
> > already
> > exists, I just don't know)
>
>
> I'm not aware, either.
> In other uses of AAA (such as with WiFi, WiMAX, 3GPP2, etc.) I know that
> the
> subscriber ID is hidden from the NAS. There are even specific methods
> deployed for that purpose. So, disclosing that ID would not be acceptable
> there. I'm just not sure if the same privacy concerns apply to the VPN
> deployments.
>
> I am not able to see these privacy concerns in VPN deployments using IKEv2.
As EAP packets are inside IKEv2 packet which is encrypted.
IKEv2 Responder asking the EAP identity before EAP authentication and IKEv2
initiator
can give provide the EAP identity which its going to use.

>
> > but surely it would be easier to define that
> > then to define a standard way to send some "policy" from AAA server to
> > IKEv2 responder. Right?
>
> If you don't do that, then you have to maintain "per subscriber policy" on
> each one of the VPN gateways. Now that starts defeating some of the purpose
> that AAA was offloaded to a centralized/dedicated server.
>
> Regards,
>
> Alper
>
>
>
> >
> >   regards,
> >
> >   Dan.
> >
> > On Tue, February 9, 2010 2:53 am, Alper Yegin wrote:
> > > Dan,
> > >
> > > I'm not aware of any such document.
> > >
> > > Alper
> > >
> > >
> > >> -Original Message-
> > >> From: Dan Harkins [mailto:dhark...@lounge.org]
> > >> Sent: Monday, February 08, 2010 8:13 PM
> > >> To: Alper Yegin
> > >> Cc: 'Yoav Nir'; 'Raj Singh'; 'Yaron Sheffer'; 'ipsec'
> > >> Subject: Re: [IPsec] Fwd: Issue : Regarding EAP identity
> > >>
> > >>
> > >>   Hi Alper,
> > >>
> > >>   What document describes how a AAA server communicates selector and
> > >> SPD information for this authenticated peer to an IKEv2 responder?
> > >>
> > >>   Dan.
> > >>
> > >> On Mon, February 8, 2010 1:41 am, Alper Yegin wrote:
> > >> > Yoav,
> > >> >
> > >> > When the IKEv2 responder offloads the Authentication,
> > Authorization,
> > >> and
> > >> > Accounting (AAA) responsibilities to a centralized AAA server, it
> > is
> > >> no
> > >> > longer in the business of figuring out who the peer is, if the
> > peer
> > >> is
> > >> > really who it claims it is, what policies to apply to the peer.
> > These
> > >> are
> > >> > the things handled by the AAA server, and communicated to the
> > IKEv2
> > >> > responder. "Policy" needs to be enforced by the IKEv2 responder,
> > but
> > >> the
> > >> > policy is determined by and communicated to the responder by the
> > AAA
> > >> > server.
> > >> >
> > >> > Alper
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >> -Original Message-
> > >> >> From: Yoav Nir [mailto:y...@checkpoint.com]
> > >> >> Sent: Thursday, February 04, 2010 3:45 PM
> > >> >> To: 'Alper Yegin'; 'Raj Singh'; Yaron Sheffer
> > >> >> Cc: 'ipsec'
> > >> >> Subject: RE: [IPsec] Fwd: Issue : Regarding EAP identity
> > >> >>
> > >> >> The IKEv2 responder enforces policy, so it has to know the
> > identity,
> > >> >> both for enforcement and auditing. Suppose y...@checkpoint.com is
> > >> >&g

Re: [IPsec] Just three more issues for IKEv2bis

[Raj Singh]

Hi Yoav,

On Fri, Feb 19, 2010 at 3:22 AM, Yoav Nir  wrote:

> Hi all.
>
> There are only three issues this time, because this is the last batch.
>
> Issue #173 - Trigger packets should not be required
> ===
> In a few places in the new section 2.23.1 in IKEv2bis, it says that one
> must have a trigger packet when starting negotiation. This assumption
> should be removed so as not to cause new requirements in IKEv2bis:
> there is no requirement for trigger packets in RFC 4306 or in the rest
> of IKEv2bis.
>
> - "When the client starts creating the IKEv2 SA and Child SA for sending
> traffic to the server, it has a triggering packet with source IP address
> of IP1, and a destination IP address of IPN2" should be changed to
> "...it may have a triggering packet...".
>
> - "The first traffic selector of TSi and TSr SHOULD have very specific
> traffic selectors including protocol and port numbers from the packet
> triggering the request" should be changed to "...SHOULD have very
> specific traffic selectors including protocol and port numbers, such as
> from the packet...".
>
> - The same change is made in the third bullet of the client list near
> the end of the section.
>
> I fully agree with this, and I think the document should be updated as
> suggested here. Moreover, section 2.9 describes the SINGLE_PAIR_REQUIRED
> error notification. Obviously you can't have both a trigger packet and a
> single_pair, so one of them should go. Trigger packets are at best
> recommended, not mandatory.
>
>
>
> Issue #174 - How to behave when EAP identity is not send by AAA
> ===
> In ikev2bis07
>
> - ikev2-bis-07 section 2.16, last paragraph 
>
>   When the initiator authentication uses EAP, it is possible that the
>   contents of the IDi payload is used only for AAA routing purposes and
>   selecting which EAP method to use. This value may be different from the
>   identity authenticated by the EAP method. It is important that policy
>   look ups and access control decisions use the actual authenticated
>   identity. Often the EAP server is implemented in a separate AAA server
>   that communicates with the IKEv2 responder. In this case, the
>   authenticated identity has to be sent from the AAA server to the IKEv2
>   responder.
>
> It says the authenticated EAP identity "has to" be send from AAA server,
> my interpretation and implementation "has to" is obvious MUST. If AAA
> doesn't send the authenticated EAP identity, what should be the
> behavior? Also, what if AAA server EAP server is not AAA server?
>
>
> There has been a lively discussion about this (a thread titled
> "Regarding EAP identity"). I can't say that the thread reached any firm
> conclusion, but a lot of ground has been covered about how AAA servers
> work, and about whether or not they communicate to the server something
> other then identity, such as policy. Despite the fact that the second A
> in AAA stands for "authorization", it was generally agreed that it is
> still the job of the IKE gateway to enforce policy, and if that policy
> comes from a AAA server, that is totally outside the scope of this
> document.
>
> So in conclusion, how about replacing "the authenticated identity has to
> be sent" with "the authenticated identity, if different from that in the
> IDi payload, has to be sent..." ? Would that satisfy everyone?
>
> "the authenticated identity, if different from that in the
IDi payload, MUST/SHOULD be sent..." would be good.

>
> Issue #175 - Better wording for NAT mobility issues
> ===
> The last bullet in 2.23 is confusing. A proposed rewrite is:
>
> Old:
>   There are cases where a NAT box decides to remove mappings that are
>   still alive (for example, the keepalive interval is too long, or the NAT
>   box is rebooted). To recover in these cases, hosts that do not support
>   other methods of recovery such as MOBIKE [MOBIKE], and that are not
>   behind a NAT, SHOULD send all packets (including retransmission packets)
>   to the IP address and port from the last valid authenticated packet from
>   the other end (that is, they should dynamically update the address). A
>   host behind a NAT SHOULD NOT do this because it opens a possible denial
>   of service attack. Any authenticated IKE packet or any authenticated
>   UDP- encapsulated ESP packet can be used to detect that the IP address
>   or the port has changed. When IKEv2 is used with MOBIKE, dynamically
>   updating the addresses described above interferes with MOBIKE's way of
>   recovering from the same situation. See Section 3.8 of [MOBIKE] for more
>   information.
>
> New:
>   There are cases where a NAT box decides to remove mappings that are
>   still alive (for example, the keepalive interval is too long, or the NAT
>   box is rebooted). This will be apparent to a host if it receives a
>   packet who

Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt

[Raj Singh]

Hi Sean,

Section 5. IANA Considerations can be reworded in-line with ikev2bis.

5. IANA Considerations

IANA has already registered the type and value for AES-CTR.

Name Number  Defined In


ENCR_AES_CTR 13  (RFC3686 )


Best regards,
Raj

On Thu, Mar 4, 2010 at 11:19 AM, Sean Shen  wrote:

> Thank you, Yoav,
> I will have it fixed, listen to this channel for other suggestions and have
> the
> revised version submitted by Mar 8th.
>
> Sean
>
>
> In your mail:
> >From: Yoav Nir 
> >Reply-To:
> >To: "'Paul Hoffman'" , IPsecme WG 
> >Subject: Re: [IPsec] Please review draft-ietf-ipsecme-aes-ctr-ikev2-05.txt
> >Date:Thu, 4 Mar 2010 07:16:55 +0200
> >
> >Paragraph 5 of section #2:
> >MUST accept any length that results in proper alignment.  It should
> >be noticed that the ESP [RFC4303] Encrypted Payload requires
> >
> > Please change "noticed" to "noted".
> >
> > Other than that, the document looks good enough for implementation.
> >
> > >A New Internet-Draft is available from the on-line Internet-Drafts
> >>directories.
> >>This draft is a work item of the IP Security Maintenance and Extensions
> Working
> Group of the IETF.
> >>
> >>  Title   : Using Advanced Encryption Standard (AES) Counter
> Mode with IKEv2
> >>  Author(s)   : S. Shen, Y. Mao, S. murthy
> >>  Filename: draft-ietf-ipsecme-aes-ctr-ikev2-05.txt
> >>  Pages   : 10
> >>  Date: 2010-3-2
> >>
> >>This document describes the usage of Advanced Encryption Standard
> >>   Counter Mode (AES-CTR), with an explicit initialization vector, by
> >>   IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT
> >>   exchange.
> >>
> >>A URL for this Internet-Draft is:
> >>
> http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-05.txt
> >
> >Based on Pasi's AD review, the authors significantly shortened the
> document. It
> seems prudent to have the WG review the new, shorter version. In
> particular, it
> would be good for developers to look at the new short document and see if
> it is
> complete enough to implement from.
> >
> >This review cycle will end in a week, but please do the review early in
> case
> problems are found.
> >
> >--Paul Hoffman, Director
> >--VPN Consortium
> >___
> >IPsec mailing list
> >IPsec@ietf.org
> >https://www.ietf.org/mailman/listinfo/ipsec
> >
> >Scanned by Check Point Total Security Gateway.
> >___
> >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
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Issue #177. (was: HA/LS terminology)

[Raj Singh]

+1
I agree with Dan.

On Wed, Mar 24, 2010 at 1:16 PM, Dan Harkins  wrote:

>
> On Tue, March 23, 2010 7:24 pm, Yoav Nir wrote:
> >
> > On Mar 23, 2010, at 6:05 PM, Dan Harkins wrote:
> >
> >>
> >>  Hi,
> >>
> >>  "hot standby" implies a box sitting ("hot") twiddling its thumbs doing
> >> little but waiting for another box to fail ("standby"). It's the VRRP
> >> model.
> >
> > And that's exactly what I want to describe. Well, not twiddling its
> > thumbs. The standby is synchronizing state with the active member, but
> > it's not doing any IKE or IPsec
>
>   Well don't use such a limiting term to describe a behavior that is
> not so limited. Not all HA is that small subset you want to describe.
>
> >>  There is a HA model which supports dynamic load balancing as well as
> >> active session failover. Nodes in such a cluster are not "standby". They
> >> each have loads that they can shed and add to based upon some heuristic.
> >> A neat attribute of such a system is that an IPsec SA can be established
> >> on node A, move to node B after a while, and come back to A some time
> >> later without any actual node failure. State moves around to keep the
> >> cluster balanced.
> >
> > Failure is just used as an example of why a certain SA failed over to
> > another member. It is by no means the only reason. Still, what you are
> > describing is a model that provides both high-availability and load
> > balancing, and that is the reason we're moving away from calling the
> first
> > model "high availability".
>
>   Of course it's not the only reason. But you're missing the point. The
> point is that the reason doesn't matter! You want to describe a particular
> reason-- the "master" crashed and all state went over to the "hot
> standby"--
> not the generic concept of state moving.
>
>  So don't call it "high availability" then. But "hot standby" is worse.
>
> >>  I would very much prefer "session failover" to "hot standby" and a
> >> mild preference of "load balancing" over "load sharing". An HA model
> >> doing VRRP could be termed "session failover" but the HA model described
> >> above really can't be called "hot standby". And load can be shared but
> >> just sharing a load can result in a mis-balanced cluster if sessions on
> >> one node terminate naturally and it sits doing little while another node
> >> whose sessions haven't terminated is huffing-and-puffing. Balancing can
> >> imply sharing but not vice versa.
> >
> > "Session failover" sounds to me more like a description of an event than
> a
> > type of cluster.
>
>   So what? Are you suggesting that a type of cluster that is not a
> "hot standby" is not worthy of terminology in IPsecME?
>
>  Your term is severely limiting. I like "session failover". If you don't
> then come up with a term that generically describes HA and not the
> particular style of HA that you are accustomed to.
>
>  Dan.
>
>
>
> ___
> 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] New PAKE Criteria draft posted (def. of gateway)

[Raj Singh]

Hi Team,

The similar scenarios are beautifully handled by Redirect RFC-5685.
The Redirect RFC emphasize on client-gateway terminology, which is typical
use of Redirect mechanism in IKEv2 where Gateway redirects client to another
less loaded gateway but at the same time RFC is also applicable to
router-router scenario when one router decides to off-load all existing
IKEv2 sessions to another gateway when it goes down for maintenance etc.
I totally agree with Paul.

Best regards,
Raj

On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman  wrote:

> 
>
> The disagreement between Dan and Yaron is over wording in the not-at-all
> normative criteria draft. This draft is not intended to become an RFC, and
> is not binding on the WG. It currently is being edited by Yaron; soon it
> will be edited by both Yaron and Dan.
>
> From the active thread the past few days, it seems that Dan disagrees with
> Yaron's view that people thinking about the PAKE primarily as a
> gateway-to-gateway solution. That's fine: others in the WG might take one
> view or the other. I ask that Dan and Yaron produce an -03 with both views
> in it. I note that the current WG charter does not insist that the PAKE we
> choose be for gateway-to-gateway, but that it does list "authentication
> between two servers or routers" as a motivating scenario, and does not list
> remote access as a motivating scenario for the proposed new work.
>
> As WG members consider which criteria are important to them, they should
> also consider what scenarios we want to emphasize in the eventual document.
> I use the word "emphasize" here because we cannot prevent implementers and
> administrators from using the new authentication mechanism however they
> want; we have plenty of experience with IKE and IPsec documents saying "you
> should use this in that way" that are merrily ignored by large parts of the
> market.
>
> --Paul Hoffman, Director
> --VPN Consortium
> ___
> 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] New PAKE Criteria draft posted (def. of gateway)

[Raj Singh]

Hi Yaron,

You are saying the same things what i am saying, then i am not able to
understand how its counter example?
The point i want to make here,
"We can emphasize the main use case scenario the draft, but protocol should
have a space for generality".
According to me RFC - 5685 is good example of the above.

Best regards,
Raj


On Tue, Mar 30, 2010 at 5:45 PM, Yaron Sheffer wrote:

> Hi Raj,
>
> this in fact is the perfect counter-example: RFC 5685 started out with the
> client-gateway scenario, and when we woke up to see how it can be
> generalized to the symmetric gateway-gateway case, it was too late. Hence
> Sec. 10, which says that the resulting protocol is a very partial solution
> for this case.
>
> 10.  Use of the Redirect Mechanism between IKEv2 Peers
>
>   The redirect mechanism described in this document is mainly intended
>   for use in client-gateway scenarios.  However, the mechanism can also
>   be used between any two IKEv2 peers.  But this protocol is
>   asymmetric, meaning that only the original responder can redirect the
>   original initiator to another server.
>
> I'm not saying that we were right in ignoring this case. I'm saying that
> you can only get the protocol that you want if you define the requirements
> clearly up front.
>
> Thanks,
>Yaron
>
>
> On 29.3.2010 16:58, Raj Singh wrote:
>
>> Hi Team,
>>
>> The similar scenarios are beautifully handled by Redirect RFC-5685.
>> The Redirect RFC emphasize on client-gateway terminology, which is
>> typical use of Redirect mechanism in IKEv2 where Gateway redirects
>> client to another less loaded gateway but at the same time RFC is also
>> applicable to router-router scenario when one router decides to off-load
>> all existing IKEv2 sessions to another gateway when it goes down for
>> maintenance etc.
>> I totally agree with Paul.
>>
>> Best regards,
>> Raj
>>
>> On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman > <mailto:paul.hoff...@vpnc.org>> wrote:
>>
>>
>>
>>The disagreement between Dan and Yaron is over wording in the
>>not-at-all normative criteria draft. This draft is not intended to
>>become an RFC, and is not binding on the WG. It currently is being
>>edited by Yaron; soon it will be edited by both Yaron and Dan.
>>
>> From the active thread the past few days, it seems that Dan
>>disagrees with Yaron's view that people thinking about the PAKE
>>primarily as a gateway-to-gateway solution. That's fine: others in
>>the WG might take one view or the other. I ask that Dan and Yaron
>>produce an -03 with both views in it. I note that the current WG
>>charter does not insist that the PAKE we choose be for
>>gateway-to-gateway, but that it does list "authentication between
>>two servers or routers" as a motivating scenario, and does not list
>>remote access as a motivating scenario for the proposed new work.
>>
>>As WG members consider which criteria are important to them, they
>>should also consider what scenarios we want to emphasize in the
>>eventual document. I use the word "emphasize" here because we cannot
>>prevent implementers and administrators from using the new
>>authentication mechanism however they want; we have plenty of
>>experience with IKE and IPsec documents saying "you should use this
>>in that way" that are merrily ignored by large parts of the market.
>>
>>--Paul Hoffman, Director
>>--VPN Consortium
>>___
>>IPsec mailing list
>>IPsec@ietf.org <mailto:IPsec@ietf.org>
>>
>>https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>>
>>
>> ___
>> 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] Complexing of Traffic Selector (TSi & TSr)

[Raj Singh]

Hi Jaemin,

If initiator narrows down the TSr, then
1. the responder is not aware of initiator has narrowed down TSr and if it
initiates a traffic which is from a broader section of range which Initiator
has not accepted, there will data black-hole.
2. I think, better solution will be, If initiator has to narrow down the
TSr, it can delete old Child SA and negotiate a new Child SA based on
knowledge of TSr that are acceptable to initiator as well as responder.

Regards,
Raj


On Sat, Jun 19, 2010 at 11:15 PM, Jaemin Park  wrote:

> Hi, Scott,
>
> I want to ask one more thing about Traffic Selector.
>
> In my case, host A and host B are working as follows about Traffic Selector
> :
>
> 1) host A (initiator) sends TS to host B (responder)
> 2) host B narrows the TS sent by host A and responses the narrowed TS to
> host A
>
> At this point, the narrowed TS includes the TSs that violates the policy of
> initiator such as different protocol IDs of TSi and TSr, etc.
> Then, can host A (initiator) also narrow the narrowed TSs, that is to
> remove the case of which the protocol IDs are different?
>
> I'm looking forward to responses.
>
> Thanks in advance.
>
> My Best Regards,
> Jaemin Park
>
> On Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen wrote:
>
>>  Hi Jaemin,
>>
>> The RFC allows you to narrow the proposed traffic selectors to something
>> smaller than what the peer proposes. From your description, it sounds like
>> StrongSwan has made a pragmatic choice to narrow the proposed selectors to
>> something symmetrical. This is allowed by the RFC. The TCP&UDP case is a
>> strange one, and in particular it doesn't accomplish much for TCP, but it is
>> allowed by the RFC. If your SPD and/or SAD pragmatically do not allow you to
>> express this sort of asymmetry for IPsec-protected traffic, then it is
>> proper for you to respond with TS_UNACCEPTABLE to such a proposal. You will
>> of course be unable to interoperate with a peer making such a proposal, but
>> in this case I'm not sure that is a great hardship.
>>
>> Also don't forget to take into account complex proposals containing more
>> than one traffic selector for TSi and/or TSr.
>>
>>
>> Scott Moonen (smoo...@us.ibm.com)
>> z/OS Communications Server TCP/IP Development
>> http://www.linkedin.com/in/smoonen
>>
>> [image: Inactive hide details for Jaemin Park ---06/18/2010 10:51:53
>> AM---Dear All,]Jaemin Park ---06/18/2010 10:51:53 AM---Dear All,
>>
>>
>> From:
>> Jaemin Park 
>> To:
>> ipsec@ietf.org
>> Date:
>> 06/18/2010 10:51 AM
>> Subject:
>> [IPsec] Complexing of Traffic Selector (TSi & TSr)
>> --
>>
>>
>>
>> Dear All,
>>
>> I'm in charge of developing VPN Clients based on IKEv2 and IPSec.
>>
>> We referred to the implementation of strongswan and RFC documents such as
>> 4306 and 4718.
>>
>> While developing, we faced one question about complexing of Traffic
>> Selectors.
>> According to the RFC 4718, complexing of TSi and TSr which have same
>> protocol IDs are defined and clarified.
>> However, in the case when TSi is (17 (udp) any any) and TSr is (ip any
>> any) where protocol IDs are different, should VPN complex TSi and TSr?
>> According to the implementation of strongswan, we could find the fact that
>> the strongswan is checking when complexing the TSi and TSr as follows :
>> 1) remove the policy which has different protocol IDs for TSi and TSr as
>> long as both of them are not "ANY"
>> 2) follow the protocol which is not "ANY" if one of TSi and TSr is "ANY"
>> According to my analysis, following examples can be possible :
>> - ANY & ANY yields ANY
>> - ANY & UDP yields UDP
>> - UDP & UDP yields UDP
>> - TCP & UDP <-- remove this case
>>
>> Does above implementation of strongswan follow the standards?
>> If so, we're planning to implement the way the strongswan supports.
>>
>> I'm looking forward to all of the experts' responses.
>>
>> My Best Regards,
>> Jaemin Park
>>
>> --
>> Park, Jae Min
>> Assistant Manager
>> Device R&D Center , Convergence WIBRO BU, KT
>> M : +82-10-3010-2658
>> T  : +82-2-2010-9255  *
>> *
>> *jmp...@kt.com* , *jmpar...@gmail.com*
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>>
>
>
> --
> Park, Jae Min
> Assistant Manager
> Device R&D Center , Convergence WIBRO BU, KT
> M : +82-10-3010-2658
> T  : +82-2-2010-9255
> jmp...@kt.com, jmpar...@gmail.com
>
> ___
> 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] Complexing of Traffic Selector (TSi & TSr)

[Raj Singh]

Hi Jaemin,

The problem is at initiator side, when its sending its TSi/TSr, it sending
some range which is violating its own policies. This is not allowed by RFC
as per section 2.9.1.

Regards,
Raj


2010/6/20 Jaemin Park 

> Dear All,
>
> I need to clarify my question.
> My question is about the way for initiator to complex the TS narrowed by
> responder.
>
> Suppose that following TSs are returned by the responder.
>
> 1) TSi = (TS1, TS2)
> 2) TSr = (TS3, TS4, TS5)
>
> While complexing, the case TS1 and TS5 need to be removed by initiator due
> to the difference of protocol ID and violation of the intended policy.
>
> Can initiator remove the above case and follow the RFC?
>
> I'm looking forward to the experts' responses.
>
> Thanks in advance.
>
> From My iPhone
>
> 2010. 6. 20. 오후 2:36 Raj Singh  작성:
>
> Hi Jaemin,
>
> If initiator narrows down the TSr, then
> 1. the responder is not aware of initiator has narrowed down TSr and if it
> initiates a traffic which is from a broader section of range which Initiator
> has not accepted, there will data black-hole.
> 2. I think, better solution will be, If initiator has to narrow down the
> TSr, it can delete old Child SA and negotiate a new Child SA based on
> knowledge of TSr that are acceptable to initiator as well as responder.
>
> Regards,
> Raj
>
>
> On Sat, Jun 19, 2010 at 11:15 PM, Jaemin Park < 
> jmpar...@gmail.com> wrote:
>
>> Hi, Scott,
>>
>> I want to ask one more thing about Traffic Selector.
>>
>> In my case, host A and host B are working as follows about Traffic
>> Selector :
>>
>> 1) host A (initiator) sends TS to host B (responder)
>> 2) host B narrows the TS sent by host A and responses the narrowed TS to
>> host A
>>
>> At this point, the narrowed TS includes the TSs that violates the policy
>> of initiator such as different protocol IDs of TSi and TSr, etc.
>> Then, can host A (initiator) also narrow the narrowed TSs, that is to
>> remove the case of which the protocol IDs are different?
>>
>> I'm looking forward to responses.
>>
>> Thanks in advance.
>>
>> My Best Regards,
>> Jaemin Park
>>
>> On Sat, Jun 19, 2010 at 12:07 AM, Scott C Moonen < 
>> smoo...@us.ibm.com> wrote:
>>
>>>  Hi Jaemin,
>>>
>>> The RFC allows you to narrow the proposed traffic selectors to something
>>> smaller than what the peer proposes. From your description, it sounds like
>>> StrongSwan has made a pragmatic choice to narrow the proposed selectors to
>>> something symmetrical. This is allowed by the RFC. The TCP&UDP case is a
>>> strange one, and in particular it doesn't accomplish much for TCP, but it is
>>> allowed by the RFC. If your SPD and/or SAD pragmatically do not allow you to
>>> express this sort of asymmetry for IPsec-protected traffic, then it is
>>> proper for you to respond with TS_UNACCEPTABLE to such a proposal. You will
>>> of course be unable to interoperate with a peer making such a proposal, but
>>> in this case I'm not sure that is a great hardship.
>>>
>>> Also don't forget to take into account complex proposals containing more
>>> than one traffic selector for TSi and/or TSr.
>>>
>>>
>>> Scott Moonen ( smoo...@us.ibm.com)
>>> z/OS Communications Server TCP/IP Development
>>> <http://www.linkedin.com/in/smoonen>http://www.linkedin.com/in/smoonen
>>>
>>> Jaemin Park ---06/18/2010 10:51:53 AM---Dear All,
>>>
>>>   
>>> From: 
>>>
>>> Jaemin Park < jmpar...@gmail.com>
>>>  
>>> To: 
>>> ipsec@ietf.org 
>>> Date: 
>>>
>>> 06/18/2010 10:51 AM
>>>  
>>> Subject: 
>>>
>>> [IPsec] Complexing of Traffic Selector (TSi & TSr)
>>> --
>>>
>>>
>>>
>>> Dear All,
>>>
>>> I'm in charge of developing VPN Clients based on IKEv2 and IPSec.
>>>
>>> We referred to the implementation of strongswan and RFC documents such as
>>> 4306 and 4718.
>>>
>>> While developing, we faced one question about complexing of Traffic
>>> Selectors.
>>> According to the RFC 4718, complexing of TSi and TSr which have same
>>> protocol IDs are defined and clarified.
>>> However, in the case when TSi is (17 (udp) any any) and TSr is (ip any
>>> any) where protocol IDs are different, should VPN complex TSi and TSr?
>>> Accor

Re: [IPsec] HA design team started

[Raj Singh]

Hi Group,

We would like to present the HA design team's output for IPsec Cluster
Solution Draft before Maastricht meeting as
http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.txt

This draft solves the main issues of IPsec Cluster Problem Statement draft
using a simple IKEv2 protocol extension, and  provides implementation advice
for other issues.

I sincerely thanks all the team members of HA Design Team for attending all
internal meetings and giving their valuable inputs and doing reviews.
My special thanks to Yaron and Yoav for their expert inputs and comments. I
would also like to thanks Paul for providing TeamSpeak server for conducting
internal design team meetings.

The team started with these draft as inputs.
1. http://tools.ietf.org/html/draft-kagarigi-ipsecme-ikev2-windowsync-00 -
G. Kalyani
2.
http://www.ietf.org/id/draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.txtJ.
Arora
3. http://www.ietf.org/id/draft-ietf-ipsecme-ipsec-ha-09.txt - Y. Nir - As
Input

The current draft is based on [1], then it got enhanced and extended with
all team's contribution.
The problem and solution presented in [2], is more towards load balancing
than HA cluster.
Also this problem can be solved using IKEv2 REDIRECT mechanism. Also, this
solution requires IKEv2
protocol change. So, this is deferred for now.

I request the IPsecME group members to review and give comments on
http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.txt, so
that we can discuss this draft with more details in Maastricht meeting.

Regards,
Raj Singh

On Fri, Jun 18, 2010 at 11:56 AM, Yaron Sheffer wrote:

> Hi,
>
> As promised, we have started a design team on IPsec HA. Paul and I have
> asked Raj Singh to lead the team. His job is to make sure that the team
> meets regularly in the next few weeks, and produces a good output document
> before the Maastricht face-to-face meeting.
>
> The initial membership of the team is:
>
> - Raj Singh (rsjen...@gmail.com, lead)
>
> - Jitender Arora (jar...@acmepacket.com)
> - Min Huang (huang...@huaweisymantec.com)
> - Dacheng Zhang (zhangdach...@huawei.com)
> - Yoav Nir (y...@checkpoint.com)
> - Yaron Sheffer (yaronf.i...@gmail.com, observer)
>
> According to IETF rules (see
> http://www.ietf.org/iesg/statement/design-team.htm), every design team
> needs to have a mission statement. So here it is:
>
> Produce a high-level solution document that covers most or all of the
> issues raised by the HA problem statement (draft-ietf-ipsecme-ipsec-ha). Any
> solution should be applicable to different deployments, in order to
> accommodate the variety of existing and future IPsec products. Solutions
> should have a similar level of security as the IKE/IPsec suite.
>
> Another process reminder: the design team's output serves as input to the
> full WG, essentially like an individual draft. So all protocol decisions
> will eventually be made by the working group.
>
> 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

[IPsec] New version of IPsec Cluster Solution Draft posted [earliar, HA design team started]

[Raj Singh]

Hi Group,

We have come up with new version of the "IPsec Cluster Solution"draft
addressing comments which we got, the new version can be find here:
http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs.<http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs>
We will submit the draft as soon as submission window re-opens.
Please read the draft and give you comments before Maastricht meeting.

Regards,
Raj


On Sun, Jul 11, 2010 at 4:39 PM, Raj Singh  wrote:

> Hi Group,
>
> We would like to present the HA design team's output for IPsec Cluster
> Solution Draft before Maastricht meeting as
> http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.txt
>
> This draft solves the main issues of IPsec Cluster Problem Statement draft
> using a simple IKEv2 protocol extension, and  provides implementation advice
> for other issues.
>
> I sincerely thanks all the team members of HA Design Team for attending all
> internal meetings and giving their valuable inputs and doing reviews.
> My special thanks to Yaron and Yoav for their expert inputs and comments. I
> would also like to thanks Paul for providing TeamSpeak server for conducting
> internal design team meetings.
>
> The team started with these draft as inputs.
> 1. http://tools.ietf.org/html/draft-kagarigi-ipsecme-ikev2-windowsync-00 -
> G. Kalyani
> 2.
> http://www.ietf.org/id/draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.txtJ.
>  Arora
> 3. http://www.ietf.org/id/draft-ietf-ipsecme-ipsec-ha-09.txt - Y. Nir - As
> Input
>
> The current draft is based on [1], then it got enhanced and extended with
> all team's contribution.
> The problem and solution presented in [2], is more towards load balancing
> than HA cluster.
> Also this problem can be solved using IKEv2 REDIRECT mechanism. Also, this
> solution requires IKEv2
> protocol change. So, this is deferred for now.
>
> I request the IPsecME group members to review and give comments on
> http://tools.ietf.org/id/draft-kagarigi-ipsecme-ikev2-windowsync-03.txt,
> so that we can discuss this draft with more details in Maastricht meeting.
>
> Regards,
> Raj Singh
>
> On Fri, Jun 18, 2010 at 11:56 AM, Yaron Sheffer wrote:
>
>> Hi,
>>
>> As promised, we have started a design team on IPsec HA. Paul and I have
>> asked Raj Singh to lead the team. His job is to make sure that the team
>> meets regularly in the next few weeks, and produces a good output document
>> before the Maastricht face-to-face meeting.
>>
>> The initial membership of the team is:
>>
>> - Raj Singh (rsjen...@gmail.com, lead)
>>
>> - Jitender Arora (jar...@acmepacket.com)
>> - Min Huang (huang...@huaweisymantec.com)
>> - Dacheng Zhang (zhangdach...@huawei.com)
>> - Yoav Nir (y...@checkpoint.com)
>> - Yaron Sheffer (yaronf.i...@gmail.com, observer)
>>
>> According to IETF rules (see
>> http://www.ietf.org/iesg/statement/design-team.htm), every design team
>> needs to have a mission statement. So here it is:
>>
>> Produce a high-level solution document that covers most or all of the
>> issues raised by the HA problem statement (draft-ietf-ipsecme-ipsec-ha). Any
>> solution should be applicable to different deployments, in order to
>> accommodate the variety of existing and future IPsec products. Solutions
>> should have a similar level of security as the IKE/IPsec suite.
>>
>> Another process reminder: the design team's output serves as input to the
>> full WG, essentially like an individual draft. So all protocol decisions
>> will eventually be made by the working group.
>>
>> 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] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04

[Raj Singh]

On Sun, Sep 5, 2010 at 11:56 AM, Yoav Nir  wrote:

>
> On Sep 4, 2010, at 3:01 PM, Kalyani Garigipati (kagarigi) wrote:
>
> >
> > 1. If window size is say some five and range expected is 4-8, and if
> > peer has got all four requests with values 5,6,7,8 and 4 is lost, then
> > there would be no message id that can be used to send the notify
> > reset_window.
> > The initiator will not know which message Id should be used to send the
> > new notify.
>
> It's actually worse than that. If message #4 was missed, and 5-8 were
> received, then messages 5-8 are stored, but not processed. This has to be
> so, because suppose message 7 deletes the SA that was created in message 4,
> you can't process it before message 4. In any case, message 4 has to be
> processed before 5,6,7, and 8. So it doesn't matter what kind of exchange or
> notifies you have in the new message, or whether it is within the message
> window or outside it. As long as message 4 was lost, the IKE SA is toast
> unless we have some special processing rules.
>

According to me, that's not very correct interpretation of windowing. My
implementation goes ahead with the processing of message if the message is
within window. Storing messages and not processing them is not very
beneficial for the purpose of windowing concept.
Related with your example, how an peer can delete an SA in message # 7, if
message # 4 to create the SA was lost, the SA is not established yet.



>
> >
> > And here the problem is not only to send the request, but also to
> > receive the request. The failover device should also know the
> > permissible range in which it can receive the requests from the peer.
> >
> > The idea to send a new informational exchange with message Id zero was
> > thought only because when the failover takes control it would not know
> > what message Id it can use to know the peer window values .This is the
> > basic problem of message Id synchronization, so having new notify itself
> > will not help.
> >
> > Regards,
> > Kalyani
>
> ___
> 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] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-00.txt

[Raj Singh]

Hi Pekka,

Thanks for your comments. Please find my reply inline.

Best Regards,
Raj



On Mon, Sep 6, 2010 at 11:13 AM, Pekka Riikonen  wrote:

>
> From the draft:
>
>   There were some concerns about the current window sync process.  The
>   concern was to make IKEv2 window sync optional but we beleive IKEv2
>   window sync will be mandatory.
>
> The IKEv2 message id sync is definitely mandatory, but the IPSEC SA seqno
> sync IMHO isn't.  Although, none of this would be an issue if IKEv2 would
> allow initiator to move the window forward freely (that would be real
> "fix").
>
> The IPsec SA replay counter sync is required for these reasons:
1.  In cluster environment, IPsec SA reply counter will get get updated from
active to standby in
 periodic manner. Suppose, we sync IPsec reply counter for every 1,000
IPsec packets and
 last sync happened at 30,000. So, the next sync will happen 31,000.
 Now, say failover happened at 30, 500. So, standby member becomes
active, and it start
using IPsec replay counter from 30, 000. It will be considered as Replay
Attack and SA has to be destroyed.
This applies to both outbound and inbound replay counters.

   So, IPsec replay counter sync is required as it mitigate the these
attacks.

2. Another option is doing IPsec Rekey after failover. Now consider a
scenario where gateways has thousands of SA.
and after failover, we are doing IPsec rekey for them. The gateway will
be so much loaded. If we follow IPsec replay counter
sync mechanism, we can sync many IPsec SA with single sync message.

So, if replay attack and load on server is OK, this option is not required.

I'm not sure if any of the following should be mentioned in the draft:
>
> - Multiple failovers.  In a cluster with three or more nodes, it's
> possible that failovers happen in rapid succession.  The protocol and the
> implementation must be able to handle new failover even if they are still
> processing the old failover (for example doing the IPSEC SA seqno sync,
> which, if we leave it in, can take time).  I see no reason why the
> protocol wouldn't allow for this, but implementations must make sure they
> can handle it.
>
> Very interesting point! Opened a ticket for it.
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/196

- Simultaneous failover at both ends.  If failover happens at the same
> time in both ends, implementations must be able to handle situation where
> they receive SYNC_SA_COUNTER_INFO request before they receive response to
> their own request (they may receive the response only after
> retransmission).
>
> I don't think we have any solution for this and any solution is possible
(?). This basically means that both sides has lost the SA.
So we have to establish SA from scratch. This draft assumes, that both side
has the SA and their message windows has mis-matched.

> - Should there be way to negotiate support for IKE SA window sync but not
> for IPSEC SA sync?  Currently by sending SYNC_SA_COUNTER_INFO_SUPPORTED
> you agree to support both, which can mean you may receive the IPSEC SA
> syncs.
>
> This is very much possible and we can have flag for IPsec SA sync in
SYNC_SA_COUNTER_INFO_SUPPORTED notify payload.
If that flag can be TRUE if we support IPsec SA sync, else we support only
IKEv2 SA sync.
More discussion on this will be interesting.

> There's also still bunch of typos in the draft.
>
>Pekka
> ___
> 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] HA protocol -01 - comments

[Raj Singh]

Hi Yaron,

Thanks for comments. We will address them in next version.

On Thu, Oct 14, 2010 at 2:27 PM, Yaron Sheffer wrote:

> Hi,
>
> the new draft is a good realization of our discussions since the previous
> version. Please see a few comments below. My main point is that if you
> choose to implement *only* replay counter sync, you should not pay the price
> of all the other stuff that we added because of the problems with Message ID
> zero. I suggest that the protocol support the following three cases:
>
> - Both Msg ID and Replay Counter sync, where both must be sent in the same
> IKE message (and so can have one protection mechanism).
> - Only Msg ID sync.
> - Only Replay Counter sync, where we use a regular Informational message.
>
> Detailed comments:
>
>  1. Abstract:  failure prone -> failure-resistant (same in intro)
>  2. "Standby member would initiate the SYNC Request with an
> INFORMATIONAL exchange with message Id zero ." It's very important
> to note that the zero message ID only applies to IKE counter sync
> (or when doing both), not to implementations that only sync IPsec
> counters.
>  3. There's no need for a nonce in the IPsec Replay Counter
> notification. Either it is sent within a regular IKE message,
> which is already replay-protected, or (when the message ID is 0)
> it is sent along with the other notification, whose nonce is
> sufficient for this purpose. Similarly for the failover count.
>  4. 6.4: the diagram should be reformatted so that it is clear which
> bit ESN is (i.e. use the letter 'E' for ESN).
>  5. 7: "IKEV2_MESSAGE_ID_SYNC exchange" - no, it's an Informational
> exchange that contains this notification.
>  6. Where is the failover count first initialized, and to what value?
>
The failover count is global parameter of HA and is generic across the
cluster. I will add some text for it.

>  7. Are there special processing rules for simultaneous failover?
> Where are they described?
>
The current protocol which shift the to higher side on each end will take
care of simultaneous failover too.
We will add one example scenario for it in next version.

>
> Thanks,
>Yaron
>
Best Regards,
Raj

> ___
> 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] draft-ietf-ipsecme-ipsecha-protocol-02.txt

[Raj Singh]

Hi Tero,

Thanks for the comments.
Opened Ticket #204 for format error in notification payload.

Regarding the second issue. Some clarification is needed:
The text meant that the message containing IKEV2_MESSAGE_ID_SYNC
notification is allowed with message id zero only.
This doesn't mean that message id is NOT allowed for other messages.

Also, Yaron has suggested another method IKEv2 Message Id sync in another
thread, after discussion further decision will be taken on this.

Thanks,
Raj


On Wed, Nov 10, 2010 at 4:48 PM, Tero Kivinen  wrote:

> I haven't had time to read the draft-ietf-ipsecme-ipsecha-protocol-02
> completely yet, but while looking at the slides in the WG meeting, I
> noticed one serious problem.
>
> The IKEV2_MESSAGE_ID_SYNC and IPSEC_REPLAY_COUNTER_SYNC messages do
> not follow Notification payload syntax.
>
> For the IKEV2_MESSAGE_ID_SYNC there is only the missing critical bit:
>
>1   2   3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Next Payload  |RESERVED   | Payload Length|
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ...
>
> instead of:
>
>1   2   3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Next Payload  |C|  RESERVED   | Payload Length|
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> For the IPSEC_REPLAY_COUNTER_SYNC it is bit more serious as it puts
> something else on the same plaCe where the C bit normally is:
>
>1   2   3
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Next Payload  |E| RESERVED| Payload Length|
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> I.e it adds "ESN bit" on the generic IKEv2 header in the location
> where normally there is the critical bit.
>
> There is not really any need for the ESN bit as the length of the
> delta value can be seen from the payload length field.
>
> --
>
> Also the section 7 says:
>
>   The Message ID value used in the Informational exchange that contains
>   the IKEV2_MESSAGE_ID_SYNC notification MUST be zero so that it is not
>   validated upon receipt as required by normal IKEv2 windowing.  The
>   Message ID zero MUST be accepted only in an Informational exchange
>   that contains a notification of type IKEV2_MESSAGE_ID_SYNC.  If any
>   Informational exchange has a Message ID zero, but not this
>   notification type, such messages MUST be discarded upon decryption
>   and the INVALID_SYNTAX notification SHOULD be sent.  Other payloads
>   MUST NOT be sent in this Informational exchange.  Whenever an
>   IKEV2_MESSAGE_ID_SYNC or IPSEC_REPLAY_COUNTER_SYNC notification
>   payload is received with an invalid failover count or invalid nonce
>   data, the event SHOULD be logged.
>
> Message ID zero is completely valid and legal value for message ID and
> this text suddenly makes it impossible to use it anymore. The first
> message responder ever always has Message ID zero, which means that if
> you follow this then first message sent by responder will be rejected.
> Message ID is also zero after IKE SA rekey. Also INVALID_SYNTAX
> notification do have some special meaning in RFC5996:
>
>   Only authentication failures (AUTHENTICATION_FAILED and EAP failure)
>   and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE
>   SA without requiring an explicit INFORMATIONAL exchange carrying a
>   Delete payload.
> 
>   If a peer parsing a request notices that it is badly formatted (after
>   it has passed the message authentication code checks and window
>   checks) and it returns an INVALID_SYNTAX notification, then this
>   error notification is considered fatal in both peers, meaning that
>   the IKE SA is deleted without needing an explicit Delete payload.
> --
> kivi...@iki.fi
> ___
> 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] HA protocol replay protection

[Raj Singh]

Hi Yaron,

Thanks for the comments, Ticket#205 create to track this.

On Thu, Nov 11, 2010 at 8:46 PM, Yaron Sheffer wrote:

> Hi,
>
> it seems to me we have created an overly complicated solution for replay
> protection of the Msg ID = 0 messages. Specifically, I think both the
> failover counter and the nonce can be eliminated.
>
> Since the messages are protected under the IKE SA, we just need to ensure
> that in a correct run of the protocol, there is never any need to repeat
> previous messages. This can be done by including *both* Msg ID counters in
> each message, and specifying a few rules to make sure counters never go
> backwards.
>
> Cluster member to client:
> - The counter I plan to use next (based on a traffic/rekey rate estimate,
> must be higher than the last message that was actually sent, otherwise it
> might be rejected)
>

It will be better to jump this counter by IKEv2 Message Send Window size
rather than measuring or guessing traffic here.


> - The counter I think you will use next (the last known value, as received
> from the failed cluster member)
>
> Client to cluster:
> - The counter I really plan to use next (must be equal to or higher than
> the received value)
> - The counter you said you will use next
>
> And each side must accept incoming messages only if both values are equal
> to or larger than the corresponding one previously received from the same
> peer, and one of them is strictly larger than the previous value.
>
> Am I missing anything?
>
> 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