Subject: Re: Re: [Ipsec] Fwd: I-D Action:draft-hoffman-ikev2bis-01.txt

From: "DIPANJAN DATTA" <[email-masked]>
Date: 13 Jun 2007 08:04:59 -0000

Hi,
I can reply to one of your queries according to my understanding of IKEv2:

1) Message Id:
One should remember that two different Message Id counters SHOULD be maintained by each peer. They are i) the next one to be used for sending a request & ii) the next one expected in a request from the peer.

So when the IKE_SA_INIT Exchange starts all the four counters are set to 0. So the first IKE_SA_INIT request send by the Initiator will have its Message Id set to 0 and the corresponding response from the Responder will also have its Message Id set to 0. If both the request & response are successful, the IKE_SA_INIT exchange is over and at that point the four above mentioned counters will have the following values:
INITIATOR                                                    
the next one to be used for sending a request = 1
the next one expected in a request from the peer = 0

RESPONDER
the next one to be used for sending a request = 0
the next one expected in a request from the peer = 1

Hence the Initiator will send the first message of IKE_AUTH Exchange with Message Id 1 and the corresponding response from the responder will also contain the same Message Id.
Now the above mentioned counters will have the following values:
INITIATOR                                                    
the next one to be used for sending a request = 2
the next one expected in a request from the peer = 0

RESPONDER
the next one to be used for sending a request = 0
the next one expected in a request from the peer = 2

Now, if the Responder sends any Request the Message Id of such a message will have value 0 and the correponding Response from the original initiator will also have Message Id set to 0.
Suppose the Original Responder sends another request, now the Message Id will be 1 and after it receives a successful response the four counters will have the following values:
INITIATOR                                                    
the next one to be used for sending a request = 2
the next one expected in a request from the peer = 2

RESPONDER
the next one to be used for sending a request = 2
the next one expected in a request from the peer = 2

Now if both the Initiator & the Responder send a request simultanously, both will have the Message Ids set to 2. To differentiate which message belongs to whom the I & R bits of the Flags from outer IKE header will be used.

I have similar doubts like yours for receiving a higher Major Version in a response during IKE_SA_INIT exchange.

Regards
Dipanjan Datta

On Tue, 12 Jun 2007 Fukumoto Atsushi wrote :
>re ikev2bis-01 section 2.2:
>    The Message ID is a 32-bit quantity, which is zero for the
>    IKE_SA_INIT messages (including retries of the message due to
>    responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}),
>    and incremented for each subsequent exchange.  Thus, the first pair
>    of IKE_AUTH messages will have ID of 1, the second (when EAP is used)
>    will be 2, and so on. {{ Clarif-3.10 }}
>
>I feel this paragraph is less clearer than -00 text.  What if EAP is
>not used?  What is the initial value for the Responder's Request?
>
>
>In section 2.5:
>    {{ 3.10.1-5 }} If an endpoint receives a message with a higher major
>    version number, it MUST drop the message and SHOULD send an
>    unauthenticated notification message of type INVALID_MAJOR_VERSION
>    containing the highest (closest) version number it supports.
>
>Hmm, is this message an INFORMATIONAL Request?  I was assuming it is
>an IKE_SA_INIT response with Notify payload, but now I'm not sure.
>
>
>Also in 2.5:
>    IKEv2 adds a "critical" flag to each payload header for further
>    flexibility for forward compatibility.  If the critical flag is set
>    and the payload type is unrecognized, the message MUST be rejected
>    and the response to the IKE request containing that payload MUST
>    include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
>    unsupported critical payload was included.
>
>What to do if unknown critical payload exist in a response message?  I
>found it's described in section 3.10, but it's a little confusing that
>only partially elaborating on what to do here.
>
>
>Section 3.3:
>                     Sometimes there is a choice of multiple algorithms,
>    whereas other times there is a combination of algorithms.  For
>    example, an initiator might want to propose using ESP with either MD5
>    or 3DES.
>
>Is this correct?  I'm not sure what is the intention to choose from
>MD5 or 3DES.
>
>
>Also in 3.3:
>    The first Proposal MUST have a Proposal # of one (1).
>
>But 3.3.1 mentions that the above MUST is only for request, and the
>response is different.  This is confusing.
>
>
>In section 3.3.2, there are algorithm values already assigned and not
>listed, though I don't know whether they should be listed here.
>
>
>In section 3.10:
>    o  Protocol ID (1 octet) - Protocol ID (1 octet) -
>
>Looks like an edit error.
>
>
>    whose SPI is given the SPI field
>
>"is given in"?
>
>
>
>Regards,
>
> 					FUKUMOTO Atsushi
> 					[email-masked]
>
>_______________________________________________
>Ipsec mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ipsec
_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec