Paul,
I haven't matched Scott's efforts, but I do have some comments:
Comment #1:
Section 1.2 (The Initial Exchanges) has the following sentence, which was
also in RFC 4306.
Payloads that may optionally appear will be shown in brackets,
such as [CERTREQ], indicate that optionally a certificate request
payload can be included.
This wording seems awkward to me. I suggest changing "indicate" to
"indicating" as below:
Payloads that may optionally appear will be shown in brackets,
such as [CERTREQ], indicating that optionally a certificate request
payload can be included.
Comment # 2:
Section 1.7 (Differences Between RFC 4306 and This Document) states:
The protocol described in this document retains the same major
version number (2) and minor version number (0) as was used in RFC
4306. That is, the version number is *not* changed from RFC 4306.
Section 2.5 (Version Numbers and Forward Compatibility) states
The minor
version number indicates new capabilities, and MUST be ignored by a
node with a smaller minor version number, but used for informational
purposes by the node with the larger minor version number. For
example, it might indicate the ability to process a newly defined
notification message. The node with the larger minor version number
would simply note that its correspondent would not be able to
understand that message and therefore would not send it.
New notifies have been added to the bis draft. Is a bump in the minor
number warranted? Is there a down side to bumping the minor number?
Comment # 3:
Section 2.8.1 Simultaneous Child SA rekeying states:
To B, it looks like A is trying to rekey an SA that no longer exists;
thus, B responds to the request with something non-fatal such as
NO_PROPOSAL_CHOSEN.
<-- send resp1: N(NO_PROPOSAL_CHOSEN)
recv resp1 <--
When A receives this error, it already knows there was simultaneous
rekeying, so it can ignore the error message.
Section 2.25.1 Exchange Collisions states:
A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
a request to rekey a Child SA that does not exist. A peer that
receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the
Child SA and send a request to create a new Child SA from scratch.
This seems to be inconsistent. I suspect that the text in section 2.8.1
should be updated to show CHILD_SA_NOT_FOUND sent instead of
NO_PROPOSAL_CHOSEN.
Comment #4:
Section 2.8.2 Simultaneous IKE SA Rekeying states:
If only one peer detects a simultaneous rekey, redundant SAs
are not created. In this case, when the peer that did not notice the
simultaneous rekey gets the request to rekey the IKE SA that it has
already successfully rekeyed, it MUST return TEMPORARY_FAILURE
because it is an IKE SA that it is currently trying to close (whether
or not it has already sent the delete notification for the SA).
Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states:
If a peer receives a request to close an IKE SA that it is
currently trying to close, it SHOULD reply as usual, and forget about
its own close request.
Based on the text in Section 2.25.2 it seems that perhaps the MUST in
Section 2.8.2 is really a SHOULD.
Comment #5
In section Section 2.8.2 Simultaneous IKE SA Rekeying I suggest we start a
new paragraph at the sentence:
If only one peer detects a simultaneous rekey, redundant SAs
are not created.
Comment #6
Section 2.25.2 (Collisions While Rekeying or Closing IKE SAs) states:
If
the peer that did notice the simultaneous rekey gets the delete
request from the other peer for the old IKE SA, it knows that the
other peer did not detect the simultaneous rekey, and the first peer
can forget its own rekey attempt.
However, there is a twist to the other case where one rekeying
finishes first:
Host A Host B
-------------------------------------------------------------------
send req1:
SA(..,SPIa1,..),Ni1,.. -->
<-- send req2: SA(..,SPIb1,..),Ni2,..
--> recv req1
<-- send resp1: SA(..,SPIb2,..),Nr2,..
recv resp1 <--
send req3: D() -->
--> recv req3
At this point, host B sees a request to close the IKE_SA. There's
not much more to do than to reply as usual. However, at this point
host B should stop retransmitting req2, since once host A receives
resp3, it will delete all the state associated with the old IKE_SA
and will not be able to reply to it.
<-- send resp3: ()
I suggest the sentence, "However, there is a twist to the other case where
one rekeying finishes first: " be deleted. The sample flow that follows it
is just a more detailed description of the sentence that proceeds it. The
sentence made sense at one time, but not anynore.
Comment 7:
Section 2.23 (Nat Traversal) has the following sequence of text:
o The recipient of either the NAT_DETECTION_SOURCE_IP or
NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
value to a SHA-1 hash of the SPIs, source IP address, and port,
and if they don't match it SHOULD enable NAT traversal. In the
case of a mismatching NAT_DETECTION_SOURCE_IP hash, the recipient
MAY reject the connection attempt if NAT traversal is not
supported. In the case of a mismatching
NAT_DETECTION_DESTINATION_IP hash, it means that the system
receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT
and that system SHOULD start sending keepalive packets as defined
in [UDPENCAPS]; alternately, it MAY reject the connection attempt
if NAT traversal is not supported.
o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
the expected value of the source IP and port found from the IP
header of the packet containing the payload, it means that the
system sending those payloads is behind NAT (i.e., someone along
the route changed the source address of the original packet to
match the address of the NAT box). In this case, the system
receiving the payloads should allow dynamic update of the other
systems' IP address, as described later.
o If the NAT_DETECTION_DESTINATION_IP payload received does not
match the hash of the destination IP and port found from the IP
header of the packet containing the payload, it means that the
system receiving the NAT_DETECTION_DESTINATION_IP payload is
behind a NAT. In this case, that system SHOULD start sending
keepalive packets as explained in [UDPENCAPS].
The first bullet says, "In the case of a mismatching
NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the connection
attempt if NAT traversal is not supported." This is slightly inaccurate
when multiple NAT_DETECTION_SOURCEIP payloads are sent. I think it should
be reworded to say, "In the case there is a mismatch of the
NAT_DETECTION_SOURCE_IP hash in each NAT_DETECTION_SOURCE_IP payloads
received, the recipient MAY reject the connection attempt if NAT traversal
is not supported.
Also, the third bullet seems to already be covered by the last sentence in
the first bullet. Is the third bullet really necessary?.
Comment 8:
Section 2.23 (Nat Traversal) I thought it was decided that one should be
able to float to port 4500 (or even start out on port 4500) even if there
is no NAT. That is is not clear from 2.23. Should floating even when a
NAT is not detected be mentioned in 2.23?
Comment 9:
I agree with Scott Moonen's comment that in Section 3.6 the sentence
"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." Does not seem to make sense.
Certificate payloads are still sent when the HTTP_CERT_LOOKUP_SUPPORTED
Notify payload. is received. I've seen Paul's response that a new ticket
should be opened if this is important. I think it is and will open a new
ticket once I figure how to.
Comment 10
In Section 3.7 (Certificate Request Payload) I still find the relationship
between the cert encoding type and the HTTP_CERT_LOOKUP_SUPPORTED notify to
be poorly explained. Perhaps there is no relationship, but it seems as if
there should be. For example, what should take precedence the case where
the cert encoding type is "Hash and URL of X.509 certificate" and no
HTTP_CERT_LOOKUP_SUPPORTED notify was sent or in the case where the cert
encoding type is "X..509 certificate" and a HTTP_CERT_LOOKUP_SUPPORTED
notify was sent?
Dave Wierbowski
From: Paul Hoffman <paul.hoff...@vpnc.org>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Date: 12/15/2009 12:28 PM
Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06
(yes, IKEv2-bis!)
Sent by: ipsec-boun...@ietf.org
At 11:53 AM -0500 12/15/09, Scott C Moonen wrote:
>I've finished my read through the draft.
Many thanks for the careful review. So, who wants to match or exceed
Scott's efforts? We need more eyes on this version of the document before
it is ready for IETF Last Call.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
