Subject: [IPsec] Comments to draft-ietf-ipsecme-ikev2bis-07.txt

From: Tero Kivinen <[email-masked]>
Date: Thu, 21 Jan 2010 17:05:21 +0200

It seems my number of lines in comment emails is going down (it was
1300 lines, then 950 lines, and now only 240 lines) so hopefully we
are getting closer to the get ready...

----------------------------------------------------------------------

In section 2.6 there is typo:

	       Also, incorporating SPi in the hash prevents an
   attacker from fetching one cookie from the other end, and then
   initiating many IKE_SA_INIT exchanges all with different initiator
   SPIs (and perhaps port numbers) so that the responder thinks that
   there are lots of machines behind one NAT box who are all trying to
   connect.

replace "SPi" with "SPIi".

----------------------------------------------------------------------

Section 2.8.2 there was removed paragraph:

	However, there is a twist to the other case where one rekeying
	finishes first:

and I think some kind of paragraph is needed, as the example given
below is not about normal simultaneous IKE SA rekey, but this special
case. Now someone might think that the example given is the normal
simulatenous IKE SA rekey example.

----------------------------------------------------------------------

In the sectioon 2.9 the "SHOULD" requirement was removed for the
very specific traffic selector as fist traffic selector.

I think that "SHOULD" requirement needs to be kept, as it affects
interoperability, as if other end does not include that triggering
packet then certain policies cannot interoperate.

Also in the interops we have seen implementations who could not
interoperate at all if sender end included triggering packet (I do not
know if the failure to create Child SA was because the traffic
selector containing port selectors, or whether it was because there
were multiple traffic selectors).

If there is "SHOULD" level requirement for that, then we can at least
point the other vendors to that and say, that as we SHOULD be sending
that triggering packet, then you also needs to be able to cope with
it...

Old text was:

   To enable the responder to choose the appropriate range in this case,
   if the initiator has requested the SA due to a data packet, the
   initiator SHOULD include as the first traffic selector in each of TSi
   and TSr a very specific traffic selector including the addresses in
   the packet triggering the request.

new text in draft-ietf-ipsecme-ikev2bis-07.txt is:

   If the initiator requests an SA because it wants to send a data
   packet, including the specific addresses in the packet triggering the
   request in the first traffic selector in both TSi and TSr enables the
   responder to choose the appropriate range.  

----------------------------------------------------------------------

In section 2.23.1:

Also there is extra "as" in this sentence:

   In this case, the server should first check that as initiator
						    ^^
   requested transport mode and do address substitution on the traffic
   selectors.  

This was already in my previous comments, and that change was not
done.

----------------------------------------------------------------------

The section 3.6 has some duplicate text:

		    Certificate payloads SHOULD be included in an
   exchange if certificates are available to the sender.  The Hash and
   URL formats of the Certificate payloads should be used in case the
   peer has indicated an ability to retrieve this information from
   elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.
-  Certificate payloads SHOULD be included in an exchange if
-  certificates are available to the sender unless the peer has
-  indicated an ability to retrieve this information from elsewhere
-  using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.  

I suggest removing the later half of the text marked with '-' in the
beginning of line.
   
----------------------------------------------------------------------

In section 3.14 we should remove the "or E" in the first sentence, as
we do not use E anymore, only SK{}

----------------------------------------------------------------------

Note, that In section 6, we need to add new IANA entry where we change
the exiting IKEv2 Payload Types table by changing:

46        Encrypted                        E          [RFC4306]

to 

46        Encrypted and Authenticated      SK         [RFCXXXX]

----------------------------------------------------------------------

In section 1.7 I do not know which change this 

   In Section 2.3, there is new material covering how the initiator's
   SPI and/or IP is used to differentiate if this is a "half-open" IKE
   SA or a new request.

item refers to. I do not find anything related to half-open IKE SAs in
the section 2.3. Also as 2.3 talks about Window Size, and Window size
is only active AFTER initial exchanges have completeled, it cannot
really be related to half-open IKE SAs.

Hmm... looking through old versions, I guess this was the change done
in the section 2.1 not 2.3:

I.e. when this text was added:

   {{ 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).	
   	
   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.

On the other hand I think the changed text allowing implementations to
forget old packets after serveral minutes, is change that will affect
implementors more, as now they do not need to keep those packets
forever, than this is. This helpful text is just implementantation
hint pointing out some possible problems if someone implemented things
wrongly.

----------------------------------------------------------------------

The section 1.7 should be more like description of changes, not just
listing section numbers with changed text. For example I think it
would be better to combine:

   In section 1.3.2, changed "The KEi payload SHOULD be included" to be
   "The KEi payload MUST be included".  This also lead to changes in
   section 2.18.

   Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
   the IKE_SA.  In theory, RFC 4306 allowed a policy where the Diffie-
   Hellman exchange was optional, but this was not useful (or
   appropriate) when rekeying the IKE_SA.

to one item saying:

   Diffie-Hellman exchange is now required for IKE SA rekeys. In
   theory, RFC 4306 allowed a policy where the Diffie- Hellman
   exchange was optional, but this was not useful (or appropriate)
   when rekeying the IKE_SA (section 1.3.2 and section 2.18).

----------------------------------------------------------------------

For example in 1.7 the point:

   This document clarifies the use of the critical flag in Section 2.5.

does not help implementors at all, as they now need to go through the
old RFC4306 section 2.5 and compare it with the new section 2.5 to
find out what was done (and I do not remember that myself, so I need
to do that to provide better text for that bullet).

----------------------------------------------------------------------

In section 1.7 the bullet

   In 2.8, changed "Note that, when rekeying, the new Child SA MAY have
   different traffic selectors and algorithms than the old one" to "Note
   that, when rekeying, the new Child SA SHOULD NOT have different
   traffic selectors and algorithms than the old one".

should be rewritten to

   In the Child SA rekey the new recommended behavior is that the new
   Child SA SHOULD NOT have different traffic selectors and algorithms
   than what was used in the old Child SA. Previously it
   was that "Child SA MAY have different traffic selectors and
   algorithms then the old one" (section 2.8).

----------------------------------------------------------------------

Also I think the new sections could be combined together i.e. replace:

   The new Section 2.8.2 covers simultaneous IKE SA rekeying.

   The new Section 2.9.2 covers traffic selectors in rekeying.

   Added Section 2.23.1 to describe NAT traversal when transport mode is
   requested.

to

   There are completely new sections covering simultaneous IKE SA
   rekeying (Section 2.8.2), traffic selectors in rekeying (Section
   2.9.2) and NAT traversal in transport mode (2.23.1).

----------------------------------------------------------------------

In general implementators are not that interested in what parts of the
text changed, they are interested in what was the real change that
affects them.

----------------------------------------------------------------------

Also I think issue #40 requires its own item, as it do change behavior
of implementations.  Added text to 2.23: 

   An initiator can use port 4500, regardless whether or not there is
   NAT, even at the beginning of IKE.  When either side is using port
   4500, sending with UDP encapsulation is not required, but
   understanding received packets with UDP encapsulation is required.
   UDP encapsulation MUST NOT be done on port 500.  If NAT-T is
   supported (that is, if NAT_DETECTION_*_IP payloads were exchanged
   during IKE_SA_INIT), all devices MUST be able to receive and process
   both UDP encapsulated and non-UDP encapsulated packets at any time.
   Either side can decide whether or not to use UDP encapsulation
   irrespective of the choice made by the other side.  However, if a NAT
   is detected, both devices MUST send UDP encapsulated packets.

This could be summarized like this:

   NAT Traversal was clarified so that now both UDP encapsulated IPsec
   packets and non-UDP encapsulated IPsec packets packets needs to be
   understood when receiving (Section 2.23).
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 Jan 2010 09:30:47 -0800

At 5:05 PM +0200 1/21/10, Tero Kivinen wrote:

All changes made other than the following.

Please open a new issue in the tracker and put specific text in it.

This difference is not worth the effort of re-writing the whole section and possibly losing information.

Clarifications such as this are welcome. Please provide text.

Those two feel equivalent to me; not done. I am quite hesitant to do wordsmithing at this stage, particularly if it could cause loss of information.

Ditto. These are equivalent.

That's a very broad claim, made by someone who already fully implemented IKEv2. Other implementers, particularly those who are in the middle of implementing IKEv2, might differ.

>of implementations.

Good catch; added in the next version.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 26 Jan 2010 14:39:19 +0200

> Please open a new issue in the tracker and put specific text in it.

Opened ticket #171.

> section and possibly losing information.

I do not think we need to rewrite whole section, but I think it would
be worth of cleaning up some of the items to better explain what is
changed, compared to just listing changed section numbers with very
cryptic texts.

And as you pointed out we do not try to include every single change,
only those which are important, meaning if we loose some information
while changing those sections then it is probably ok, as if we do not
notice we are loosing important information then that information we
loose cannot be very important, thus it can be left out anyways.

This is section listing changes happening in otherwhere in the
document, so we cannot really loose real information. Everything here
needs to be something that is already explained somewhere else.

> Clarifications such as this are welcome. Please provide text.

Hmm.. I think this comment is about the this added text in IKEv2bis
(by looking at the diff of section 2.5 between RFC4306 and
draft-ietf-ipsecme-ikev2bis-07):

		     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.

So the more descriptive text could be:

  This document clarifies that critical flag MUST NOT be used in
  response messages, and that critical flag applies only to the
  payload type, note the contents (Section 2.5). 

> Those two feel equivalent to me; not done. I am quite hesitant to do
> wordsmithing at this stage, particularly if it could cause loss of
> information.

Yes, I tried to write them so they are equivalent, but I think it is
better to try to explain the change in normal words, than just provide
diff. If diff would be enough, then we could just point everybody to
the rfcdiff between RFC4306 vs IKEv2bis.

> Ditto. These are equivalent.

Yes, but same reason again. Put emphasis on the new information, not
to new section numbers.

> That's a very broad claim, made by someone who already fully
> implemented IKEv2. Other implementers, particularly those who are in
> the middle of implementing IKEv2, might differ.

If someone are middle of implementing IKEv2 then either they have
already implemented something that needs to be changed, in which case
they are interested what parts of text that affects them has changeed,
or they have not yet implemented that part, in which case that change
does not interest them at all, in which case they just ignore the old
RFC4306 and directly read new IKEv2bis text.

If they are new to IKEv2 they do not need this section at all, as it
is not important to know what was before, if they are just trying to
see what they need to make for their implementation. 
-- 
[email-masked]