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).
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
