Subject: Re: [IPsec] Some (ok, a lot) comments to ikev2bis

From: Paul Hoffman <[email-masked]>
Date: Sat, 20 Sep 2008 19:27:43 -0700

At 3:09 AM +0300 7/29/08, Tero Kivinen wrote:
>Here is my comments to the draft-hoffman-ikev2bis-03.txt. As Pasi said
>I need to include new text for all of them before they will be
>accepted, I had to make this email quite long... Still wasn't manage
>to include new text for all of my comments, but I hope the editors can
>still understand and accept even those comments :-)

Whew.

There are three types of responses. Each type has a different effect on
the new WG issue tracker. My responses are marked with "===" at the
beginning of the line.

- Done. This is now in my working copy of -01. Yaron won't fill these
in the tracker.

- Not done, but take it to the list. This is not a simple editorial
change or clarification, and needs to be taken to the list for discussion.
Yaron will mark these in the tracker as open issues.

- Not done and disagree. Some of these are editorial changes that make
things harder to understand, others are disagreements about whether they
are correct. Yaron will mark these in the issue tracker as closed issues;
someone can re-open them if sufficiently motivated.

>  1.  Introduction
>
>     IKE performs mutual authentication between two parties and
>     establishes an IKE security association (SA) that includes shared
>     secret information that can be used to efficiently establish SAs for
>     Encapsulating Security Payload (ESP) [ESP] and/or Authentication
>     Header (AH) [AH] and a set of cryptographic algorithms to be used by
>     the SAs to protect the traffic that they carry.  In this document,
>     the term "suite" or "cryptographic suite" refers to a complete set of
>     algorithms used to protect an SA.  An initiator proposes one or more
>     suites by listing supported algorithms that can be combined into
>     suites in a mix-and-match fashion.  IKE can also negotiate use of IP
>     Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA.
>     We call the IKE SA an "IKE_SA".  The SAs for ESP and/or AH that get
>     set up through that IKE_SA we call "CHILD_SAs".

I think all of those "ESP and/or AH" should be changed to "ESP or AH"
just to clarify that there cannot bve combined ESP and AH, so

s/and\/or/or/g;

===Done

>     The second request/response (IKE_AUTH) transmits identities, proves
>     knowledge of the secrets corresponding to the two identities, and
>     sets up an SA for the first (and often only) AH and/or ESP CHILD_SA.

Should already say here that even if the child sa creation fails in
here, the IKE sa is created and stays up i.e:

    The second request/response (IKE_AUTH) transmits identities, proves
    knowledge of the secrets corresponding to the two identities, and
    sets up an SA for the first (and often only) AH or ESP CHILD_SA
    (unless there is failure setting up the AH or ESP CHILD_SA, in
    which case the IKE SA is still established without IPsec SA).

===Done

>  1.2.  The Initial Exchanges
...
>     HDR, SK {IDi, [CERT,] [CERTREQ,]
>         [IDr,] AUTH, SAi2,
>         TSi, TSr}  -->
>
>     The initiator asserts its identity with the IDi payload, proves
>     knowledge of the secret corresponding to IDi and integrity protects
>     the contents of the first message using the AUTH payload (see
>     Section 2.15).  It might also send its certificate(s) in CERT
>     payload(s) and a list of its trust anchors in CERTREQ payload(s).  If
>     any CERT payloads are included, the first certificate provided MUST
>     contain the public key used to verify the AUTH field.  The optional
>     payload IDr enables the initiator to specify which of the responder's
>     identities it wants to talk to. This is useful when the machine on
>     which the responder is running is hosting multiple identities at the
>     same IP address.  The initiator begins negotiation of a CHILD_SA

I think we might want to say something about here that IDr is only
hint for the responder of which ID to use, i.e if the IDr is not
acceptable for the responder, he might use some other IDr on the next
packet and finish the exchange (as they have already done some of the
expensive calculations, like Diffie-Hellman). If the initiator then
does not accept that fact that responder used different IDr that which
was requested, it can close the SA after noticing the fact.

===Done

>     same IP address.  The initiator begins negotiation of a CHILD_SA
>     using the SAi2 payload.  The final fields (starting with SAi2) are
>     described in the description of the CREATE_CHILD_SA exchange.
>
>                                  <--  HDR, SK {IDr, [CERT,] AUTH,
>                                           SAr2, TSi, TSr}
>
>     The responder asserts its identity with the IDr payload, optionally
>     sends one or more certificates (again with the certificate containing
>     the public key used to verify AUTH listed first), authenticates its
>     identity and protects the integrity of the second message with the
>     AUTH payload, and completes negotiation of a CHILD_SA with the
>     additional fields described below in the CREATE_CHILD_SA exchange.
>
>     The recipients of messages 3 and 4 MUST verify that all signatures
>     and MACs are computed correctly and that the names in the ID payloads
>     correspond to the keys used to generate the AUTH payload.
>
>     {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange
>     fails for some reason, the IKE_SA is still created as usual.  The
>     list of responses in the IKE_AUTH exchange that do not prevent an
>     IKE_SA from being set up include at least the following:
>     NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
>     INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.

In the case of the that kind of failure the return packet will then be
without the SAr2, Tsi, and TSr, i.e.:

                                 <--  HDR, SK {IDr, [CERT,] AUTH,
                                          N(error_for_child_sa)}

If the authentication fails in such ways that the entries cannot
create IKE SA (authentication failure or similar), then the response
will be unencrypted, unauthenticated notify. There is no point of
sending the notify encrypted and integrity protected, as it is not
authenticated (as initiator and responder have not yet verified the
AUTH payloads):

                                 <--  HDR, N(error_for_ike_sa)

The initiator receiving such reply MUST NOT immediately stop the SA
creation, but it should still retransmit the message few times, in
case that error notify was forgery and the real responder will reply
with valid reply. It can use the recipient of such message as a hint
to tell that authentication failed, thus it can shorten the
retransmission timers from few minutes down to few tens of seconds.

===Not done. This is interesting, but should be discussed on the list.

>  1.3.  The CREATE_CHILD_SA Exchange
...
>     The CREATE_CHILD_SA response for creating a new CHILD_SA is:
>
>                                  <--  HDR, SK {SA, Nr, [KEr],
>                                           TSi, TSr}
>
>     The responder replies (using the same Message ID to respond) with the
     		  	   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is confusing, as we have not introduced message id at all at this
point. I suggest removing the "(using the same Message ID to
respond)".

===Not done. Disagree. It is important here.
			  
>  1.3.2.  Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange
>
>     The CREATE_CHILD_SA request for rekeying an IKE_SA is:
>
>     Initiator                         Responder
>     -------------------------------------------------------------------
>     HDR, SK {SA, Ni, [KEi]} -->
>
>     The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
>     payload, and a Diffie-Hellman value in the KEi payload.  The KEi
>     payload SHOULD be included.  New initiator and responder SPIs are
>     supplied in the SPI fields.

Add text where the SPIs fields are:

      New initiator and responder SPIs are supplied in the SPI fields,
      of SA payload.

===Done.

>     The CREATE_CHILD_SA response for rekeying an IKE_SA is:
>
>                                  <--  HDR, SK {SA, Nr,[KEr]}
>
>     The responder replies (using the same Message ID to respond) with the

Same here with the "using the same Message ID to respond)".

===Not done. Disagree. It is important here.

>  1.3.3.  Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange
...
>     {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a
>     CREATE_CHILD_SA exchange if the purpose of the exchange is to replace
>     an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is
>     identified by the SPI field in the Notify payload; this is the SPI
>     the exchange initiator would expect in inbound ESP or AH packets.
>     There is no data associated with this Notify type.

Add clarification here specifying the value of the Protocol ID field:

     The Protocol ID field of REKEY_SA notify is set accordingly to ESP
     (3) or AH (2).

===Not done. Disagree. There may be additional protocol IDs in the future.

>     The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
>
>                                  <--  HDR, SK {SA, Nr, [KEr],
>                                           Si, TSr}

There is missing T in the picture:

                                 <--  HDR, SK {SA, Nr, [KEr],
                                          TSi, TSr}

===Done

>     The responder replies (using the same Message ID to respond) with the

Again the  "using the same Message ID to respond)".

===Not done. Disagree. It is important here.

>     accepted offer in an SA payload, and a Diffie-Hellman value in the
>     KEr payload if KEi was included in the request and the selected
>     cryptographic suite includes that group.
>
>     The traffic selectors for traffic to be sent on that SA are specified
>     in the TS payloads in the response, which may be a subset of what the
>     initiator of the CHILD_SA proposed.

Add comment about which traffic selectors to use in the rekeying:

     When doing rekeying the traffic selectors SHOULD come from the
     original decorrelated policy, i.e. not the same traffic selectors
     which the old SA had in case the responder narrowed them, but from
     the policy which initiator used originally to create the IPsec SA.
     This allows the SA to expand to full traffic selector set allowed
     by latest (perhaps changed) policy.

===Not done. This is interesting, but should be discussed on the list.

Also I think we should mention that the traffic selectors for the
rekying should have those selectors from the packet (see section 2.9):

     To allow responder to do intelligent narrowing of the traffic
     selector the responder should know which packet triggered the
     rekeying, so it will not narrow the traffic selectors to set which
     is not usable for the packet triggering the rekeying. This means
     that even the traffic selectors for the rekeying needs to have
     those selectors from the packet (see section 2.9). Note, that if
     the responders policy has changed, it is possible that originally
     traffic that fit to one SA cannot fit to one SA anymore, which
     means the responder will narrow the traffic selectors so that not
     all original traffic fits to SA anymore. In that case the
     initiator getting packet that only fits the old SA (which is
     waiting to be deleted) but not new, should create new SA for this
     traffic too (but it is not rekeying anymore, so no REKEY_SA notify
     is included in the exchange). Same thing happens when the original
     SA expires, and one ends gets packet which not fit the current
     traffic selectors, but instead triggers new SA creation.

===Not done. This is interesting, but should be discussed on the list.

>  1.5.  Informational Messages outside of an IKE_SA
...
>     {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE
>     INFORMATIONAL exchange when a node receives an ESP or AH packet with
>     an invalid SPI.  The Notification Data contains the SPI of the
>     invalid packet.  This usually indicates a node has rebooted and
>     forgotten an SA.  If this Informational Message is sent outside the
>     context of an IKE_SA, it should only be used by the recipient as a
>     "hint" that something might be wrong (because it could easily be
>     forged).

If the notification data is used for the SPI of the invalid packet,
how can the recipient of such notify know whether that SPI was for ESP
or AH? As far as I can see, it cannot, but I think it does not matter
as SPIs are now supposed to be unique (i.e. protocol is no loger
include as key). Perhaps we should just note this fact here?

===Not done. This is interesting, but should be discussed on the list.

>     {{ Clarif-7.7 }} There are two cases when such a one-way notification
>     is sent: INVALID_IKE_SPI and INVALID_SPI.  These notifications are
>     sent outside of an IKE_SA.  Note that such notifications are
>     explicitly not Informational exchanges; these are one-way messages
>     that must not be responded to.  In case of INVALID_IKE_SPI, the
>     message sent is a response message, and thus it is sent to the IP
>     address and port from whence it came with the same IKE SPIs and the
>     Message ID copied.  In case of INVALID_SPI, however, there are no IKE
>     SPI values that would be meaningful to the recipient of such a
>     notification.  Using zero values or random values are both
>     acceptable.

In a sense INVALID_MAJOR_VERSION is also this kind of notification
which is sent outside of an IKE_SA, altought it is sent as a response
to the incoming IKE SA creation. Perhaps we should note this fact
here?

===Not done. This is interesting, but should be discussed on the list.

>  1.6.  Requirements Terminology
...
>     IKEv2 (and IKEv1) developers have noted that there is a great deal of
>     material in the tables of codes in Section 3.10.1.  This leads to
>     implementers not having all the needed information in the main body
>     of the docment.  Much of the material from those tables has been
     	    ^^^^^^^

Typo.

===Done.

>  2.1.  Use of Retransmission Timers
...
>     For every pair of IKE messages, the initiator is responsible for
>     retransmission in the event of a timeout.  The responder MUST never
>     retransmit a response unless it receives a retransmission of the
>     request.  In that event, the responder MUST ignore the retransmitted
>     request except insofar as it triggers a retransmission of the
>     response.  The initiator MUST remember each request until it receives
>     the corresponding response.  The responder MUST remember each
>     response until it receives a request whose sequence number is larger
>     than or equal to the sequence number in the response plus its window
>     size (see Section 2.3).

One of the problems here is that if we are using large window size, we
have to keep that many messages for ever. It would be nice, we the
responder of the request, could forget the response packet after lets
say 10 minutes after it sent it out to requestor. There is no reason
why the other end should be allowed to resend his request 4 hours
later and expect that other end can still resend reply back. So
suggest adding:

    Responder are allowed to forget response after long timeout for the
    memory saving purposes. The timeout must be longer than several
    minutes that could be used for the retransmission timers of the
    other end.

===Not done. This is a change to the protocol. The WG might want it,
but it will have to be an explicit decision from the WG.

>     IKE is a reliable protocol, in the sense that the initiator MUST
>     retransmit a request until either it receives a corresponding reply
>     OR it deems the IKE security association to have failed and it
>     discards all state associated with the IKE_SA and any CHILD_SAs
>     negotiated using that IKE_SA.
>
>     {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require
>     some special handling.  When a responder receives an IKE_SA_INIT
>     request, it has to determine whether the packet is retransmission
>     belonging to an existing "half-open" IKE_SA (in which case the
>     responder retransmits the same response), or a new request (in which
>     case the responder creates a new IKE_SA and sends a fresh response),
>     or it belongs to an existing IKE_SA where the IKE_AUTH request has
>     been already received (in which case the responder ignores it).

There is also the case of the invalid ke and cookie notifies, i.e we
need to add comment about those too:

    ...  or it belongs to an existing IKE_SA where the IKE_AUTH request has
    been already received (in which case the responder ignores it), or
    it is INVALID_KE_PAYLOAD or COOKIE notify responses to the
    IKE_SA_INIT request.

===Not done. This is interesting, but should be discussed on the list.

>     It is not sufficient to use the initiator's SPI and/or IP address to
>     differentiate between these three cases because two different peers
>     behind a single NAT could choose the same initiator SPI.  Instead, a
>     robust responder will do the IKE_SA lookup using the whole packet,
>     its hash, or the Ni payload.

We might want to also explicitly say that the retransmissions from the
initiator MUST be bitwise identicdal to the original request. We do
say that for the responses, but I do not think we have explicit text
about for the requests.

===Done.

>  2.2.  Use of Sequence Numbers for Message ID
>
>     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.

Add text:

    The Message ID is reset to zero also after IKE SA rekey for the new
    IKE SA.

===Not done. This is interesting, but should be discussed on the list.

>     Note that Message IDs are cryptographically protected and provide
>     protection against message replays.  In the unlikely event that
>     Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be
>     closed.  Rekeying an IKE_SA resets the sequence numbers.
            ^
	     or rekeyed.

===Done.

>  2.3.  Window Size for Overlapping Requests
...
>     An IKE endpoint MUST wait for a response to each of its messages
>     before sending a subsequent message unless it has received a
>     SET_WINDOW_SIZE Notify message from its peer informing it that the
>     peer is prepared to maintain state for multiple outstanding messages
>     in order to allow greater throughput.

Or the text about allowed to forget responses after some long time
could be here too instead of the section 2.1.

===Not done. This is a change to the protocol. The WG might want it,
but it will have to be explicit.

>  2.4.  State Synchronization and Connection Timeouts
...
>     payload that contains no payloads).  If a cryptographically protected
>     message has been received from the other side recently, unprotected
>     notifications MAY be ignored.  Implementations MUST limit the rate at
>     which they take actions based on unprotected messages.

I suggest adding "fresh" to the sentence there i.e.:

      If a cryptographically protected fresh (i.e. not retransmissions)
      message has been received from the other side recently,
      unprotected notifications MAY be ignored

===Dpme

>  2.5.  Version Numbers and Forward Compatibility
...
>     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. {{ 3.10.1-1 }} In that
>     Notify payload, the notification data contains the one-octet payload
>     type.  If the critical flag is not set and the payload type is
>     unsupported, that payload MUST be ignored.  Payloads sent in IKE
>     response messages MUST NOT have the critical flag set.  Note that the
>     critical flag applies only to the payload type, not the contents.  If
>     the payload type is recognized, but the payload contains something
>     which is not (such as an unknown transform inside an SA payload, or
>     an unknown Notify Message Type inside a Notify payload), the critical
>     flag is ignored.

What if such UNSUPPORTED_CRITICAL_PAYLOAD error happens during the
initial IKE_SA_INIT message, or do we forbid enchancements and
modifications which might cause such error?

===Not done. This is interesting, but should be discussed on the list.

>     NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the
>     order shown in the figures in Section 2?  Can we eliminate the
>     requirement in the following paragraph?  If not, we will probably
>     have to add a new appendix with the order, but there is no reason to
>    do that if no one actually cares. {{ Remove this paragraph before the
>     document is finalized, of course. }}

Our implemnentation do not care about the order of the payloads except
in some specific places (CERT payloads and so on).

===Note done. We still need to hear from others.

>     {{ Demoted the SHOULD in the second clause }}Although new payload
>     types may be added in the future and may appear interleaved with the
>     fields defined in this specification, implementations MUST send the
>     payloads defined in this specification in the order shown in the
>     figures in Section 2; implementations are explicitly allowed to
>     reject as invalid a message with those payloads in any other order.

I would really like to change this to say that payloads must be
accepted in any order, but implementations should try to send them out
in the order shown in the figures. Exceptions to this is the CERT
payloads (the end entity cert MUST be first), and REKEY and COOKIE
notifies.

===Not done. This is interesting, but should be discussed on the list.

>  2.6.  Cookies

This should probably be renamed to "IKE SA SPIs and Cookies".

===Done.

>     Unlike ESP and AH where only the recipient's SPI appears in the
>     header of a message, in IKE the sender's SPI is also sent in every
>     message.  Since the SPI chosen by the original initiator of the
>     IKE_SA is always sent first, an endpoint with multiple IKE_SAs open
>     that wants to find the appropriate IKE_SA using the SPI it assigned
>     must look at the I(nitiator) Flag bit in the header to determine
>     whether it assigned the first or the second eight octets.

Our implementation originally only checked its own SPI half, and
didn't verify that the other ends SPI half didn't change. This was
found out in the interop, and we fixed it to check the other ends SPI
also, but I wonder should we say one way or the other here? Also what
SPI should the response have, i.e. the SPIs from the request, or the
SPIs from the original IKE SA creation. I think it might be easier to
just say, that implementations can use their own SPI to find the IKE
SA data, but MUST also check that the other ends SPI matches the SPIs
stored with IKE SA data.

===Not done. This is interesting, but should be discussed on the list.

...
>     A good way to do this is to set the responder cookie to be:
>
>     Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

I was starting to wonder if that Cookie should also include the Port
part, especially in the NAT-T case?

===Not done. This is interesting, but should be discussed on the list.

>     where <secret> is a randomly generated secret known only to the
>     responder and periodically changed and | indicates concatenation.
>     <VersionIDofSecret> should be changed whenever <secret> is
>     regenerated.  The cookie can be recomputed when the IKE_SA_INIT
>     arrives the second time and compared to the cookie in the received
>     message.  If it matches, the responder knows that the cookie was
>     generated since the last change to <secret> and that IPi must be the
>     same as the source address it saw the first time.  Incorporating SPIi
>     into the calculation ensures that if multiple IKE_SAs are being set
>     up in parallel they will all get different cookies (assuming the
>     initiator chooses unique SPIi's).  Incorporating Ni into the hash

The real reason to hash the SPIs to the cookie is to make sure that
attacker cannot fetch one one cookie from the other end, and then
initiate 100 IKE_SA_INIT exchanges all with different initiator SPIs
(and perhaps port numbers) so that the for the responder it looked
like there is lots of machines behind one NAT box who are all trying
to connect. As the cookie is tied to the SPIi the attacker cannot use
cookie multiple times.

===Not done. This is interesting, but should be discussed on the list.

>     {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request
>     containing a cookie whose contents do not match the value expected,
>     that party MUST ignore the cookie and process the message as if no
>     cookie had been included; usually this means sending a response
>     containing a new cookie.

We might want to add text here saying:

    Initiator should limit the number of cookie exchanges it tries
    before giving up, especially as if the attacker decides to forge
    multiple cookie responses to the initiators IKE_SA_INIT message,
    each of those forged cookie reply will trigger 2 packets, one
    packet from the initiator to the responder (which will reject those
    cookies), and one reply from responder to initiator giving out
    correct cookie.

===Done.

>  2.6.1.  Interaction of COOKIE and INVALID_KE_PAYLOAD
>
>     {{ This section added by Clarif-2.4 }}
>
>     There are two common reasons why the initiator may have to retry the
>     IKE_SA_INIT exchange: the responder requests a cookie or wants a
>     different Diffie-Hellman group than was included in the KEi payload.
>     If the initiator receives a cookie from the responder, the initiator
>     needs to decide whether or not to include the cookie in only the next
>     retry of the IKE_SA_INIT request, or in all subsequent retries as
>     well.
>
>     If the initiator includes the cookie only in the next retry, one
>     additional roundtrip may be needed in some cases.  An additional
>     roundtrip is needed also if the initiator includes the cookie in all
>     retries, but the responder does not support this.  For instance, if
>     the responder includes the SAi1 and KEi payloads in cookie
>     calculation, it will reject the request by sending a new cookie.
>
>     If both peers support including the cookie in all retries, a slightly
>     shorter exchange can happen.  Implementations SHOULD support this
>     shorter exchange, but MUST NOT fail if other implementations do not
>     support this shorter exchange.

We should also explain better what this slightly shorter exchange is,
and what other options there are. I think clarification had more text
about this that could be copied her.e

===Done.

>  2.7.  Cryptographic Algorithm Negotiation
...
>     Each IPsec protocol proposal contains one or more transforms.  Each
>     transform contains a transform type.  The accepted cryptographic
>     suite MUST contain exactly one transform of each type included in the
>     proposal.  For example: if an ESP proposal includes transforms
>     ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256,
>     AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one
>     of the ENCR_ transforms and one of the AUTH_ transforms.  Thus, six
>     combinations are acceptable.

Perhaps we should add here paragraph explaining the most common reason
of the multiple propsoals:

    If both combined mode ciphers and normal ciphers with integrity
    protection needs to be proposed, the inititor needs to use two
    proposals. One of them includes all the combined mode ciphers,
    without the integrity algorithms (as combined mode ciphers are not
    allowed to have any other integrity algorithm than none), and the
    another includes normal ciphers and the integrity algoritms for
    them.

===Not done. This level of specificity is not needed, and we don't talk
about combined modes in the original IKEv2 doc.

>  2.8.  Rekeying
...
>     {{ Demoted the SHOULD }} The node that initiated the surviving
>     rekeyed SA should delete the replaced SA after the new one is
>     established.

I think this paragraph is in bit funny place, perhaps move it to some
better location.

===Note done. It is fine where it is.

>  2.8.1.  Simultaneous CHILD_SA rekeying

Instead of simultaneous CHILD_SA rekeying, there should be section of
simultaneous IKE SA rekeying. Simultaneous CHILD_SA rekeying just
results few extra SAs that will disappear after next rekeys (at worst
there will be 2 SA pairs, but all others will be deleted instead of
being rekeyed as they are not used. The simultaneous IKE SA rekeying
is much more important case to get correct, as both ends MUST agree on
which IKE SA survive, as otherwise they will move the CHILD SA to
wrong IKE SA and their state is completely messed up after that. This
section should also explain that even if the simultaneous rekeying of
IKE SA is noticed only AFTER the whole rekeying is already finished,
both ends MUST still correctly detect it and act based on the fact
which IKE SA will survive. This means that the old IKE SA should not
be deleted too quickly after the IKE SA rekey finished, just in case
there happened to be simultaneous rekey in progress. The one doing the
delete should wait at least few minutes before deleting the old IKE
SA, so it can be sure that other end does not have simultaneous rekey
going on the IKE SA.

===Not done. More specific text is needed. This is interesting, but
should be discussed on the list.

>  2.8.2.   Rekeying the IKE_SA Versus Reauthentication
...
>     Although rekeying the IKE_SA may be important in some environments,
>     reauthentication (the verification that the parties still have access
>     to the long-term credentials) is often more important.

I disagree with that statement, and I think we should not have this
kind of opinions in the document, as they do not really give any new
information for the protocol point of view. So I suggest removing the
whole paragraph.

===Not done. It explains the motivation for the rest of the section. It
is true that it is "often" more important.

>  2.9.  Traffic Selector Negotiation
>
>     {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives
>     an IP packet and matches a "protect" selector in its Security Policy
>     Database (SPD), the subsystem protects that packet with IPsec.  When
>     no SA exists yet, it is the task of IKE to create it.  Maintenance of
>     a system's SPD is outside the scope of IKE (see [PFKEY] for an
>     example protocol), though some implementations might update their SPD
>     in connection with the running of IKE (for an example scenario, see
>     Section 1.1.3).

I do not think we should be using PFKEY as example there, as it does
not support IKEv2. That could of course be new work item for the WG
some day, i.e. update of the PFKEY document to update IKEv2, but
before we have that, we should not point to it, it will just cause
confusion.

===Done. Actually, pointed out that PFKEY is for IKEv1 only.

>     The first of the two TS payloads is known as TSi (Traffic Selector-
>     initiator).  The second is known as TSr (Traffic Selector-responder).
>     TSi specifies the source address of traffic forwarded from (or the
>     destination address of traffic forwarded to) the initiator of the
>     CHILD_SA pair.  TSr specifies the destination address of the traffic
>     forwarded to (or the source address of the traffic forwarded from)
>     the responder of the CHILD_SA pair.  For example, if the original
>     initiator requests the creation of a CHILD_SA pair, and wishes to
>     tunnel all traffic from subnet 192.0.1.* on the initiator's side to
>     subnet 192.0.2.* on the responder's side, the initiator would include
>     a single traffic selector in each TS payload.  TSi would specify the
>     address range (192.0.1.0 - 192.0.1.255) and TSr would specify the
>     address range (192.0.2.0 - 192.0.2.255).  Assuming that proposal was
>     acceptable to the responder, it would send identical TS payloads
>     back.  (Note: The IP address range 192.0.2.* has been reserved for
>     use in examples in RFCs and similar documents.  This document needed
>     two such ranges, and so also used 192.0.1.*.  This should not be
>     confused with any actual address.)

I think we should use only the one example network that has been
reserved for that purpose, i.e get the rid of the 192.0.1.* address
space. As we do use ranges in all cases in the IKEv2, there is no
reason why the networks need to be /24 subnets. How about using

192.0.2.0/25 (i.e. 192.0.2.0 - 192.0.2.127) and
192.0.2.128/25 (i.e. 192.0.2.128 - 192.0.2.255) instead.

===Not done. People really relate to /24s much better.

Otherwise we might want to add comment to all other places having that
192.0.1.* network (which is actually used much more than the real
example network of 192.0.2.*).

===Not done. Developers reading this document understand what is going on.

...
>     o  If the responder's policy allows it to accept the first selector
>        of TSi and TSr, then the responder MUST narrow the traffic
>        selectors to a subset that includes the initiator's first choices.
>        In this example above, the responder might respond with TSi being
>        (192.0.1.43 - 192.0.1.43) with all ports and IP protocols.

Or it can also return some bigger range that is subset of the
initiators offer.

===Not done. That is covered by the first sentence.

>     o  If the responder's policy does not allow it to accept the first
>        selector of TSi and TSr, the responder narrows to an acceptable
>        subset of TSi and TSr.
>
>     When narrowing is done, there may be several subsets that are
>     acceptable but their union is not.  In this case, the responder
>     arbitrarily chooses one of them, and MAY include an

I do not think the responder can arbitrarily choose one of them, it
MUST select the one that includes the first TS if it was acceptable.

===Not done. This is a technical change. This is interesting, but
should be discussed on the list.

>  2.9.1.  Traffic Selectors Violating Own Policy
>
>     {{ Clarif-4.12 }}
>
>     When creating a new SA, the initiator needs to avoid proposing
>     traffic selectors that violate its own policy.  If this rule is not
>     followed, valid traffic may be dropped.

We should note here, that if you follow the RFC 4301 and use
decorrelated policies, then this kind of policy violations cannot
happen.

===Done.

>  2.15.  Authentication of the IKE_SA
...
>     RestOfRespIDPayload = IDType | RESERVED | InitIDData
     			  	   	       ^^^^

Should be RespIDData.

===Done.

>     MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
>
>     Note that all of the payloads are included under the signature,
>     including any payload types not defined in this document.  If the
>     first message of the exchange is sent twice (the second time with a
>     responder cookie and/or a different Diffie-Hellman group), it is the
>     second version of the message that is signed.

The first message might be sent more than twice, in case both
INVALID_KE_PAYLOAD and COOKIE exchanges happen, i.e. change to:

     If the first message of the exchange is sent multiple times (i.e
     with a responder cookie (or even multiple of cookie exchanges)
     and/or a different Diffie-Hellman group), it is the last version
     of the message that is signed.

===Done.

>  2.16.  Extensible Authentication Protocol Methods
...
>     In addition to authentication using public key signatures and shared
>     secrets, IKE supports authentication using methods defined in RFC
>     3748 [EAP].  Typically, these methods are asymmetric (designed for a
>     user authenticating to a server), and they may not be mutual. {{ In
>     the next sentence, changed "public key signature based" to "strong"
>     }} For this reason, these protocols are typically used to
>     authenticate the initiator to the responder and MUST be used in
>     conjunction with a strong authentication of the responder to the

This change is quite big protocol change to the bits on the wire, and
also opens word "strong" to interpretation. I.e. what is strong
authentication? As this is not defined here to vendors might implement
that differently and result versions which cannot interoperate,
because of this different interpretation.

===Done.

>  2.19.  Requesting an Internal Address on a Remote Network
...
>     {{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by
>     responder in the case where CP(CFG_REQUEST) was expected but not
>     received, and so is a conflict with locally configured policy.  There
>     is no associated data.

This should be combined with last paragraph in this section:

>     The responder MUST NOT send a CFG_REPLY without having first received
>     a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
>     to perform an unnecessary configuration lookup if the IRAC cannot
>     process the REPLY.  In the case where the IRAS's configuration
>     requires that CP be used for a given identity IDi, but IRAC has
>     failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and
>     terminate the IKE exchange with a FAILED_CP_REQUIRED error.

===Done (simple move).

We should also mention here that the FAILED_CP_REQUIRED is not fatal
error to the IKE SA, it just cause the CHILD SA creation fail on the
IKE_AUTH, but the IKE SA should be still created, and initiator can
fix this by initiating new configuration payload request later.

===Done.

>  2.21.  Error Handling
...
>     A node receiving such an unprotected Notify payload MUST NOT respond
>     and MUST NOT change the state of any existing SAs.  The message might
>     be a forgery or might be a response the genuine correspondent was
>     tricked into sending. {{ Demoted two SHOULDs }} A node should treat
     	    	 	     	     	 	      	    ^^^^^^

I think that should still be capital SHOULD.

===Not done. "...SHOULD treat as a hint..." is meaningless from an
implementation standpoint.

>     such a message (and also a network message like ICMP destination
>     unreachable) as a hint that there might be problems with SAs to that
>     IP address and should initiate a liveness test for any such IKE_SA.
>     An implementation SHOULD limit the frequency of such tests to avoid
>     being tricked into participating in a denial of service attack.
>
>     A node receiving a suspicious message from an IP address with which
>     it has an IKE_SA MAY send an IKE Notify payload in an IKE
>     INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The
>     recipient MUST NOT change the state of any SAs as a result, but may
>     wish to audit the event to aid in diagnosing malfunctions.  A node
>     MUST limit the rate at which it will send messages in response to
>     unprotected messages.

We should also extend this section and include at least following
cases:

    - Errors happening before authentication
    - Errors in the IPsec SA creation on IKE_AUTH
    - Describe which errors are so fatal that they cause the whole IKE
      SA to destroyed.

===Not done. Each of these are interesting, and need to be taken up
individually on the list.

>  2.23.  NAT Traversal
...
>     Opening an IPsec connection through a NAT introduces special
>     problems.  If the connection runs in transport mode, changing the IP
>     addresses on packets will cause the checksums to fail and the NAT
>     cannot correct the checksums because they are cryptographically
>     protected.  Even in tunnel mode, there are routing problems because
>     transparently translating the addresses of AH and ESP packets
>     requires special logic in the NAT and that logic is heuristic and
>     unreliable in nature.  For that reason, IKEv2 can negotiate UDP
     		  	   	    	    	   ^^^^^^^^^^^^^

We do not have negotiation for UDP encapsulation, we just start using
it when we detect NAT. I.e change to "will use".

===Done.

>     encapsulation of IKE and ESP packets.  This encoding is slightly less
>     efficient but is easier for NATs to process.  In addition, firewalls
>     may be configured to pass IPsec traffic over UDP but not ESP/AH or
>     vice versa.
>
>     It is a common practice of NATs to translate TCP and UDP port numbers
>     as well as addresses and use the port numbers of inbound packets to
>     decide which internal node should get a given packet.  For this
>     reason, even though IKE packets MUST be sent from and to UDP port
>     500, they MUST be accepted coming from any port and responses MUST be
         ^

Add "or 4500".

==Done.

>     sent to the port from whence they came.  This is because the ports
>     may be modified as the packets pass through NATs.  Similarly, IP
>     addresses of the IKE endpoints are generally not included in the IKE
>     payloads because the payloads are cryptographically protected and
>     could not be transparently modified by NATs.
>
>     Port 4500 is reserved for UDP-encapsulated ESP and IKE.  When working
>     through a NAT, it is generally better to pass IKE packets over port
>     4500 because some older NATs handle IKE traffic on port 500 cleverly
>     in an attempt to transparently establish IPsec connections between
>     endpoints that don't handle NAT traversal themselves.  Such NATs may
>     interfere with the straightforward NAT traversal envisioned by this
>     document.

Everything after the first sentence in the paragraph is just
misleading and should be removed.

===Not done. This was generally agreed to, I believe.

>              {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT
>     between it and its correspondent MUST send all subsequent traffic
>     from port 4500, which NATs should not treat specially (as they might
>     with port 500).

>     o  To tunnel IKE packets over UDP port 4500, the IKE header has four
>        octets of zero prepended and the result immediately follows the
>        UDP header.  To tunnel ESP packets over UDP port 4500, the ESP
>        header immediately follows the UDP header.  Since the first four
>        octets of the ESP header contain the SPI, and the SPI cannot
>        validly be zero, it is always possible to distinguish ESP and IKE
>        messages.

We should also list whether it is allowed to float to port 4500 even
when no NAT is detected (I think the answer is yes). And even if we
float to port 4500, the UDP encapsulation should not be enabled or
expected unless NAT between is really detected.

===Not done. This was debated on the list at least once in the past
and we came up with this wording, but I think it should be debated
again now that we have much more implementation experience.

>     o  Implementations MUST process received UDP-encapsulated ESP packets
>        even when no NAT was detected.
>
>     o  The original source and destination IP address required for the
>        transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
>        are obtained from the Traffic Selectors associated with the
>        exchange.  In the case of NAT traversal, the Traffic Selectors
>        MUST contain exactly one IP address, which is then used as the
>        original IP address.

Getting original source and destination IP address from the traffic
selectors do not really work currently. Especially when combined with
the selectors from the packet and when responder is behind nat or
similar problems.

===Not done. Specify replacement text and discuss on the mailing list.

>     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 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 (i.e., dynamically
>        update the address).  A host behind a NAT SHOULD NOT do this
>        because it opens a DoS attack possibility.  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.

This paragraph should here point out that MOBIKE changes this behivor,
and point to the MOBIKE documents for more information.

===Not done, but will most likely be. Supply exact text and discuss on
the mailing list.

>     Note that similar but probably not identical actions will likely be
>     needed to make IKE work with Mobile IP, but such processing is not
>     addressed by this document.

This should most likely be removed now and add pointers to the MOBIKE
and other documents.

===Done. But we still want the MOBIKE changes above.

>  3.1.  The IKE Header
...
>     o  Major Version (4 bits) - Indicates the major version of the IKE
>        protocol in use.  Implementations based on this version of IKE
>        MUST set the Major Version to 2.  Implementations based on
>        previous versions of IKE and ISAKMP MUST set the Major Version to
>        1.  Implementations based on this version of IKE MUST reject or
>        ignore messages containing a version number greater than 2.

Change to

    Implementations based on this version of IKE MUST reject or
    ignore messages containing a version number greater than 2 with
    INVALID_MAJOR_VERSION notify (see section 2.5 for more details).

===Done.

>     o  Exchange Type (1 octet) - Indicates the type of exchange being
>        used.  This constrains the payloads sent in each message and
>        orderings of messages in an exchange.
	^^^^^^^^^

What does that try to say?

===Not done. It is saying that exchange types can impose orderings.

>        *  I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages
>           sent by the original initiator of the IKE_SA and MUST be
>           cleared in messages sent by the original responder.  It is used
>           by the recipient to determine which eight octets of the SPI
>           were generated by the recipient.

Add clarification here, that the Inititor bit does not change even if
IKE SA is rekeyed (regardless who rekeys it).

===Done.

>  3.3.  Security Association Payload
...
>     The Proposal structure contains within it a Proposal # and an IPsec
>     protocol ID.  Each structure MUST have a proposal number one (1)
>     greater than the previous structure.  The first Proposal in the
>     initiator's SA payload MUST have a Proposal # of one (1).  A proposal
>     of AH or ESP would have two proposal structures, one for AH with
>     Proposal #1 and one for ESP with Proposal #2.

I think the last sentence should be removed, as it is bit confusing
and some people might read it "AH and ESP" and interpret it as
bundles. I do not really consider AH or ESP style proposal that
common to require example here. Perhaps ESP with combined mode ciphers
and ESP with normal ciphers + integrity algorithms would make better
example.

===Not done. The current example is clearer than your proposed change
because few people understand combined modes, even if the current
example is far-fetched. A different, clearer example would be a good
replacement for the current text.

>  3.3.2.  Transform Substructure
...
>     (*) Negotiating an integrity algorithm is mandatory for the
>     Encrypted payload format specified in this document. Future
>     documents may specify additional formats based on authenticated
>     encryption, in which case a separate integrity algorithm is not
>     negotiated.

We already have the future documents ready, and they are in the rfc
editor queue, so we can add reference here.

===Done.

>  3.3.3.  Valid Transform Types by Protocol
...
>     (*) Negotiating an integrity algorithm is mandatory for the
>     Encrypted payload format specified in this document. Future
>     documents may specify additional formats based on authenticated
>     encryption, in which case a separate integrity algorithm is not
>     negotiated.

Same change here.

===Done.

>  3.3.6.  Attribute Negotiation
>
>     During security association negotiation initiators present offers to
>     responders.  Responders MUST select a single complete set of
>     parameters from the offers (or reject all offers if none are
>     acceptable).  If there are multiple proposals, the responder MUST
>     choose a single proposal.  If the selected proposal has multiple
>     Transforms with the same type, the responder MUST choose a single
>     one.  Any attributes of a selected transform MUST be returned
>     unmodified.  The initiator of an exchange MUST check that the
>     accepted offer is consistent with one of its proposals, and if not
>     that response MUST be rejected.

One of the questions that have been out long time, is that do all of
the offered proposals must have identical Diffie-Hellman group lists.
What does it mean if one of the proposals have different list than
some other proposal. Can the KE payload include then be from such
group that only exists in one of the lists. Also do the Diffie-Hellman
groups need to be repeated on every single proposal.

I think we should add some text explaining that.

===Not done. Clearly, the WG needs to decide what to do here first.

>  3.5.  Identification Payloads
...
>     ID_RFC822_ADDR                      3
>         A fully-qualified RFC822 email address string, An example of a
>         ID_RFC822_ADDR is, "[email-masked]".  The string MUST not
>         contain any terminators.

As there was reference added to the IDNA in the FQDN case, should we
also refer here to the international email addresses specification?

===Done.

>  3.6.  Certificate Payload
...
>        Certificate Encoding                 Value
>        ----------------------------------------------------
>        RESERVED                             0
>        PKCS #7 wrapped X.509 certificate    1   UNSPECIFIED
>        PGP Certificate                      2   UNSPECIFIED
>        DNS Signed Key                       3   UNSPECIFIED
>        X.509 Certificate - Signature        4
>        Kerberos Token                       6   UNSPECIFIED
>        Certificate Revocation List (CRL)    7
>        Authority Revocation List (ARL)      8
>        SPKI Certificate                     9   UNSPECIFIED
>        X.509 Certificate - Attribute        10
>        Raw RSA Key                          11
>        Hash and URL of X.509 certificate    12
>        Hash and URL of X.509 bundle         13
>        RESERVED to IANA                     14 - 200
>        PRIVATE USE                          201 - 255

Actually the certificate encodings 8 (Authority Revocation List (ARL))
and 10 (X.509 Certificate - Attribute) are not specified in this
document at all, so either they should be put as UNSPECIFIED or
documentation for them needs to be added (perhaps just sharing type 4
and 7 descriptions).

===Done (as making them unspecified).

>     o  X.509 Certificate - Signature (4) contains a DER encoded X.509
>        certificate whose public key is used to validate the sender's AUTH
>        payload.

That certificate can also bve used as part of the chain. I.e. add

    or used in the validation.

to the end of that paragraph.

===Not done. It already says this.

>  3.7.  Certificate Request Payload
>
>     The Certificate Request Payload, denoted CERTREQ in this memo,
>     provides a means to request preferred certificates via IKE and can
>     appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
>     Certificate Request payloads MAY be included in an exchange when the
>     sender needs to get the certificate of the receiver.  If multiple CAs
>     are trusted and the cert encoding does not allow a list, then
>     multiple Certificate Request payloads SHOULD be transmitted.

I think the "SHOULD" there could be lowercase should as this is not
really a protocol issue.

===Done.

>  3.13.1.  Traffic Selector

I think we should add here text which says that if the TS type is
unknown, then the recipient will skip that traffic selector over, and
ignore it, so that it will not be returned in the narrowed set (i.e.
responder will narrow selection so that the unknown TS type is not
part of the narrowed traffic selectors returned to initiator). This
allows adding more traffic selector types without breaking things in
the future. The current generic text only specifies that processing
for unknown payloads, but does not say anything about the subtypes
inside the different payloads (like unknown ID types, or unknown TS
types).

===Done, but added to 2.9 instead.

>  3.14.  Encrypted Payload
>
>     The Encrypted Payload, denoted SK{...} or E in this memo, contains
>     other payloads in encrypted form.  The Encrypted Payload, if present
>     in a message, MUST be the last payload in the message.  Often, it is
>     the only payload in the message.
>
>     The algorithms for encryption and integrity protection are negotiated
>     during IKE_SA setup, and the keys are computed as specified in
>     Section 2.14 and Section 2.18.
>
>     This document specifies the cryptographic processing of Encrypted
>     payloads using a block cipher in CBC mode and an integrity check
>     algorithm that computes a fixed-length checksum over a variable size
>     message.  The design is modeled after the ESP algorithms described in

As we already has document which describes how to use other ciphers in
the IKE, we at least put the reference to there, or even incorporate
the changes specified in there to this document. Especially as the
RFCF 4307 specifies ENCR_AES_CTR as SHOULD for the IKEv2...

===Done. Well, not the way that you wanted. I will send in an errata to
RFC 4307 saying that AES_CTR should not have been listed.

>  3.15.1.  Configuration Attributes
...
>     o  INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
>        internal network, sometimes called a red node address or private
>        address and MAY be a private address on the Internet. {{
>        Clarif-6.2}} In a request message, the address specified is a
>        requested address (or a zero-length address if no specific address
>        is requested).  If a specific address is requested, it likely
>        indicates that a previous connection existed with this address and
>        the requestor would like to reuse that address.  With IPv6, a
>        requestor MAY supply the low-order address octets it wants to use.
>        Multiple internal addresses MAY be requested by requesting
>        multiple internal address attributes.  The responder MAY only send
>        up to the number of addresses requested.  The INTERNAL_IP6_ADDRESS
>        is made up of two fields: the first is a 16-octet IPv6 address,
>        and the second is a one-octet prefix-length as defined in
>        [ADDRIPV6].  The requested address is valid until there are no
>        IKE_SAs between the peers.

Perhaps move most of this explination to the 3.15.3 or at least add
pointer to there.

===Done (pointer added).

Also I think the text "The requested address is valid until there are
no IKE_SAs between the peers." is incorrect, it most likely should say
"The requested address is valid as long as this IKE SA (or its rekeyed
successors) requesting the address is valid."

I.e. even if another IKE SA is created between the peers that does not
keep the address allocated in another IKE SA alive, unless it is also
allocated in that IKE SA. This is especially the case where lets say
multi user hosts do per user IKE SAs and want to allocate IP addresses
separately for each user.

===Not done. This should be discussed on the mailing list.

...
>     o  INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined for
>        IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only
>        retained for compatibility with RFC 4306.

I think there is no point of keeping the "compatibility with RFC 4306"
for feature that cannot be used. I would simply remove the whole
INTERNAL_IP6_NBNS and mark it RESERVED.

===Not done. This should be discussed on the mailing list.

...
>     o  INTERNAL_IP4_SUBNET - The protected sub-networks that this edge-
>        device protects.  This attribute is made up of two fields: the
>        first being an IP address and the second being a netmask.
>        Multiple sub-networks MAY be requested.  The responder MAY respond
>        with zero or more sub-network attributes.

Add pointer to 3.15.2.

===Done.

...
>     o  INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-
>        device protects.  This attribute is made up of two fields: the
>        first is a 16-octet IPv6 address, and the second is a one-octet
>        prefix-length as defined in [ADDRIPV6].  Multiple sub-networks MAY
>        be requested.  The responder MAY respond with zero or more sub-
>        network attributes.

Add pointer to 3.15.2.

===Done.

>  3.15.2.  Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET
...
>     For instance, if there are two subnets, 192.0.1.0/26 and
>     192.0.2.0/24, and the client's request contains the following:

Again here we use 192.0.1.0/26 address range which is not reserved for
examples. Would suggest using 192.0.2.128/26 (192.0.2.128-191) and
192.0.2.0/25 (192.0.2.0-127) to be used instead.

===Not done.

>  3.15.4.  Address Assignment Failures
>
>     {{ Added this section from Clarif-6.8 }}
>
>
>
>
>  Kaufman, et al.          Expires August 28, 2008              [Page 101]
>  
>  Internet-Draft                  IKEv2bis                   February 2008
>
>
>     If the responder encounters an error while attempting to assign an IP
>     address to the initiator during the processing of a Configuration
>     Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification.
>     {{ 3.10.1-36 }} If this error is generated within an IKE_AUTH
>     exchange, no CHILD_SA will be created.  However, there are some more
>     complex error cases.

Add comment there, that the IKE SA is still created even if the
initial child sa cannot be created.

===Done.

>  3.16.  Extensible Authentication Protocol (EAP) Payload
...
>     {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an
>     indication of initiator identity in message 3 of the protocol, the
>     responder should not send EAP Identity requests.  The initiator may,
>     however, respond to such requests if it receives them.

This is again bits on the wire protocol change if someone after this
does not follow the SHOULD NOT and SHOULD written here before. I think
it should be kept as it was before.

===Not done. Disagree about this being bits on the wire because the responder
might have sent the request anyway.

>  4.  Conformance Requirements
...
>     Every implementation MUST be capable of doing four-message
>     IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
>     one for ESP and/or AH).  Implementations MAY be initiate-only or
     	    	 ^^^^^^
Change to "or".

===Done.

>  5.1.  Traffic selector authorization
...
>     For example, the PAD might be configured so that authenticated
>     identity "sgw23.example.com" is allowed to create IPsec SAs for
>     192.0.2.0/24, meaning this security gateway is a valid
>     "representative" for these addresses.  Host-to-host IPsec requires
>     similar entries, linking, for example, "fooserver4.example.com" with
>     192.0.1.66/32, meaning this identity a valid "owner" or
>     "representative" of the address in question.

Again using the non example prefix of 192.0.1.66/32. Would be better
to use smaller subnets and addresses from example prefix.

===Not done.

>     As noted in [IPSECARCH], "It is necessary to impose these constraints
>     on creation of child SAs to prevent an authenticated peer from
>     spoofing IDs associated with other, legitimate peers."  In the
>     example given above, a correct configuration of the PAD prevents
>     sgw23 from creating IPsec SAs with address 192.0.1.66, and prevents
>     fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24.

===Not done. (Assuming you wanted the IP addresses changed.)

>  Appendix C.  Exchanges and Payloads
...
>  C.1.  IKE_SA_INIT Exchange
>
>     request             --> [N(COOKIE)],
>                             SA, KE, Ni,
>                             [N(NAT_DETECTION_SOURCE_IP)+,
>                              N(NAT_DETECTION_DESTINATION_IP)],
>                             [V+]
>
>     normal response     <-- SA, KE, Nr,
>     (no cookie)             [N(NAT_DETECTION_SOURCE_IP),
>                              N(NAT_DETECTION_DESTINATION_IP)],
>                             [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
>                             [V+]

Add other versions of possible replies here too:

      cookie request      <-- N(COOKIE)
			     [V+]
     
      invalid ke payload  <-- N(INVALID_KE_PAYLOAD)
      error  		     [V+]

      combined cookie     <-- N(COOKIE), N(INVALID_KE_PAYLOAD)
      request and invalid     [V+]
      ke payload error

===Done.

>  C.2.  IKE_AUTH Exchange without EAP
>
>     request             --> IDi, [CERT+],
>                             [N(INITIAL_CONTACT)],
>                             [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
>                             [IDr],
>                             AUTH,
>                             [CP(CFG_REQUEST)],
>                             [N(IPCOMP_SUPPORTED)+],
>                             [N(USE_TRANSPORT_MODE)],
>                             [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
>                             [N(NON_FIRST_FRAGMENTS_ALSO)],
>                             SA, TSi, TSr,
>                             [V+]
>
>     response            <-- IDr, [CERT+],
>                             AUTH,
>                             [CP(CFG_REPLY)],
>                             [N(IPCOMP_SUPPORTED)],
>                             [N(USE_TRANSPORT_MODE)],
>                             [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
>                             [N(NON_FIRST_FRAGMENTS_ALSO)],
>                             SA, TSi, TSr,
>                             [N(ADDITIONAL_TS_POSSIBLE)],
>                             [V+]

Same here:

     error in CHILD SA   <--  IDr, [CERT+],
     creation	  	     AUTH,
    			     N(error)
			     [V+]

===Done.

>  C.4.  CREATE_CHILD_SA Exchange for Creating or Rekeying CHILD_SAs
>
>     request             --> [N(REKEY_SA)],
>                             [CP(CFG_REQUEST)],
>                             [N(IPCOMP_SUPPORTED)+],
>                             [N(USE_TRANSPORT_MODE)],
>                             [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
>                             [N(NON_FIRST_FRAGMENTS_ALSO)],
>                             SA, Ni, [KEi], TSi, TSr
>
>     response            <-- [CP(CFG_REPLY)],
>                             [N(IPCOMP_SUPPORTED)],
>                             [N(USE_TRANSPORT_MODE)],
>                             [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
>                             [N(NON_FIRST_FRAGMENTS_ALSO)],
>                             SA, Nr, [KEr], TSi, TSr,
>                             [N(ADDITIONAL_TS_POSSIBLE)]

And here:

     error case           <-- N(error)

     invalid ke payload	 <-- N(INVALID_KE_PAYLOAD)

     next request with    --> [N(REKEY_SA)],
     new ke payload using     [CP(CFG_REQUEST)],
     group given by	     [N(IPCOMP_SUPPORTED)+],
     invalid ke payload	     [N(USE_TRANSPORT_MODE)],
     notify		     [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
			     [N(NON_FIRST_FRAGMENTS_ALSO)],
			     SA, Ni, [KEi], TSi, TSr
     (response would be same as in normal case).
			    
===Done. Well, did the first two. The last is no different than
the original request. I suspect you wanted to change something
in it; if so, please re-submit.

>  Appendix D.  Changes Between Internet Draft Versions

I guess the sections here should mention draft numbers too, as now
there is two changes from -00 to -01 draft:

===Done.

>  D.1.  Changes from IKEv2 to draft -00
>  D.2.  Changes from draft -00 to draft -01
>  D.3.  Changes from draft -00 to draft -01
>  D.4.  Changes from draft -01 to draft -02
>     Added Clarif-4.4 to the ned of Section 3.3.2.
     	  	     	     ^^^
Typo.

===Done.

>  D.5.  Changes from draft -02 to draft -03
>     PRF_HMAC_TIGER              3         (RFC2104)

What is unspecified in tiger, does not the rfc 2104 specify how to use
PRF_HMAC_TIGER?

===Not done. The base spec for TIGER is not generally available.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 25 Sep 2008 09:43:42 +0300

> but it will have to be an explicit decision from the WG.

The easy answer for this concern is not to use large window sizes. For  
example, with a window size of 1, you only save 1 response. I really  
don't see the value is large window sizes, as a pair of peers will  
usually only have a handful of SAs and those are maintained for a long  
period of time. Unless you are benchmarking tunnel setup rates, or  
have an extreme latency problem (as in you peer is on Mars, not when  
your peer is in China) a window size of 1 is usually good enough.

Given that implementations will use window sizes greater than 1, and  
that keeping even one packet indefinitely is not good engineering,  
there may be value in allowing the responder to forget the response.  
This should IMO be aligned with a requirement by the initiator to stop  
transmitting. So we should decide on some X (3 minutes?) and say  
something like this:

    Responders MAY forget responses X minutes after first generating
    them, as retransmissions of the requests are expected to be done
    by then. Responders SHOULD ignore all subsequent retransmissions
    of the request. Initiators MUST cease retransmitting requests if
    no response has been received within X minutes. In such a case,
    the Initiator MUST deem the IKE SA to have failed.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Sep 2008 15:54:15 +0300

...
>     the Initiator MUST deem the IKE SA to have failed.

As we do not have any specific time interval mentioned in the RFC
about the retransmissions in general (except "at least a dozen times
over a period of at least several minutes"), I think we do NOT want to
put any specific time here. I think it is better to just say that the
time limit used when forgetting responses should be longer than the
other end's retransmission timers.  The end forgetting the response,
cannot of course know the exact timer used, thus we cannot say any
that the time MUST/SHOULD be longer.

Adding text about the responders ignoring retransmissions after that
is good and needed (it MUST NOT fail the IKE SA in those cases, as
that would open DoS attack).

I am not sure if we need the text saying that Initiators MUST cease
retransmitting, as that is normally what happens anyways if no
response is received from the other end, but having that text there
might clarify things even more.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec