David Wierbowski writes:
> 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?
Even if we add new notifies, that does not need we MUST increment the
minor version number. It just say we might want to do it.
For error notifications (which were the ones we are adding) this is
not that important as the 3.10.1 is quite clear that the corresponding
request has failed entirely when you get error notification back.
This means it does not matter which error other end sends (old or new)
the recipient of it still knows the request failed.
It would be different if other end would need to know whether other
end supports new notifications before
> 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.
Yes. Not all the old sections were properly updated yet. I try to go
them through soon to verify they are correct.
> 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.
We need to think what will happen if someone does not follow the rule.
For example those two cases are not same (in 2.8.2 incoming message is
IKE SA rekey and in 2.25.2 it is IKE SA delete) also what happens if
the MUST/SHOULD is not followed is different. In the 2.8.2 if other
end does not send TEMPORARY_FAILURE but instead replies normally that
will cause there to be simultanous IKE SA rekey, which will mean that
both ends need to look up the nonces and decide which of the exchanges
won.
As the end who decided not to send TEMPORARY_FAILURE was the one who
decided this, he should be able to cope with that if he decided to do
that. For the other end this just looks like normal simultaneous
rekey, thus it will process it as normally.
This means nothing bad happens even if someone does not follow the
"MUST return TEMPORARY_FAILURE", thus we can safely change it to
"SHOULD return TEMPORARY_FAILURE", so I agree your proposal to change
it to SHOULD.
I will try to go these things through also when I am going through the
new text, i.e. check where (if anywhere) we need to have MUST, and
where we can have SHOULD (or even MAY).
> 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?.
I think we should keep the third bullet, but remove the last sentence
of the first bullet and change the first bullet to be:
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 or it MAY
reject the connection attempt if NAT traversal is not allowed by
policy.
Anyways it is bit funny to say we can reject the connection attempt
if NAT traversal is not supported, but if the end was able to parse
NAT_DETECTION_*_IP notifications it does have at least partial NAT
traversal support, so I think it is better to say "if NAT traversal is
not allowed by policy."
> 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?
Isn't this clear enough:
An initiator can float to 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.
> 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?
I would think they mean about the same, but not exactly.
I.e. if you request Hash and URL of X.509 certificate that clearly
indicates you support fetching stuff from URL and also X.509
certificates, and it also indicates you would want certificates in the
Hash and URL format.
If you request X.509 certificate and send also
HTTP_CERT_LOOKUP_SUPPORTED that means that you support X.509
certificates, and you also support http lookups, and you prefer
getting certificates using Hash and URL format, but you also accept
the other end to send them in X.509 format if it cannot do Hash and
URL.
Note, that also in the first case if other end getting Hash and URL of
X.509 certificate request cannot do Hash and URL, it can still send
the certificates inband using X.509 as certificate request payloads
are just hints:
The intent is not to prevent communication through the strict
adherence of selection of a certificate based on CERTREQ, when an
alternate certificate could be selected by the sender that would
still enable the recipient to successfully validate and trust it
through trust conveyed by cross-certification, CRLs, or other out-of-
band configured means. Thus, the processing of a CERTREQ should be
seen as a suggestion for a certificate to select, not a mandated one.
If no certificates exist, then the CERTREQ is ignored. This is not
an error condition of the protocol. There may be cases where there
is a preferred CA sent in the CERTREQ, but an alternate might be
acceptable (perhaps after prompting a human operator).
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
