[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IKEv2 draft 6 (details)
(1) *If* we decide to include a peer address update payload, we should
take this into account in the Abstract and in the Overview (1-).
(2) IMHO it can be useful to add the "proxy case" (transport mode IPsec
SAs negociated on the behalf of a third party) in the Usage Scenarios (3-).
I have a full subsection in draft-dupont-ikev2-addrmgmt-02.txt but
a simple statement can be enough. Note this (the proxy case) is very
useful in mobile and/or multi-homed environments.
(3) NAT detection is performed in the IKE_SA_INIT so the descriptions
at the beginning of the Initial Exchanges (1.2-) should be updated
(or we should state that notifications are not included in order to
keep the descriptions simple. IMHO this is the best and applies to
descriptions of not INFORMATIONAL exchanges too).
(4) In the section 1.5 (Informational Messages outside of an IKE_SA)
we should be more accurate and give the notification to send.
(5) Section 2 (IKE Protocol Details and Variations) is a good place
to explain that an IKE SA is identified by its SPI and *not* by
the addresses in the IP header of the message.
(6) Section 2.1 (Use of Retransmission Timers) must specify what
is in a message (request or response) to retransmit: this contains
only the IKE header and payloads, as defined in section 3.
So a peer MAY retransmit a message from and/or to a different address.
BTW in section 3 the used term is "IKE message" so I propose
to add IKE before the word message at least at the first occurrence
of each subsection.
(7) I don't like the wording of section 2.3 (Window Size) because
it is not enough accurate about the allowed (un)sequencing of
the processing of requests. IMHO the device is a message transmission
facility, not an out of order processing. If we give the possibility
as suggested in the current text to process requests out of order,
then we should be very careful with peer address updates which must
be processed strictly in order...
(8) We should repeat in 2.3 the point 6 in order to be as clear as
possible.
(9) The terms IRAC and IRAS must be introduced in section 2.19
(Requesting an internal address on a remote network) before being
used!
(10) in Error Handling (2.21) please change:
If a node receives a message on UDP port 500 outside the context of
into
If a node receives a message on UDP port 500 or 4500 outside the context of
(11) This text in section 3.5 (Identification Payload) is not sound:
Two implementations will interoperate only if each can generate a
form of ID acceptable to the other. To assure maximum
interoperability, implementations MUST be configurable to send at
least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
MUST be configurable to accept all of these forms. Implementations
SHOULD be capable of generating and accepting all of these forms.
perhaps it should be:
Two implementations will interoperate only if each can generate a
form of ID acceptable to the other. To assure maximum
interoperability, implementations MUST be capable of accepting all
of these forms and MUST be configurable to accept all of these forms.
Implementations SHOULD be capable of generating all of these forms,
and MUST be configurable to send at least one of ID_IPV4_ADDR,
ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID.
(12) I disagree with the current wording for NAT_DETECTION_*_IP
in section 3.10.1 (Notify Message Types): NAT detection and NAT traversal
support should be made mandatory, so we should change the MAYs into MUSTs
and the term supported by the term enabled (note that an implementation
which doesn't allow to enable NAT traversal should be still conformant,
so some care is needed in the NAT traversal support requirement).
I propose to change:
NAT_DETECTION_SOURCE_IP 24582
This notification is used to by its recipient to determine
whether the source is behind a NAT box. The data associated
with this notification is a SHA-1 digest of the SPIs, IP
address and port on which this packet was sent. There MAY
be multiple notify payloads of this type in a message if the
sender does not know which of several network attachments
will be used to send the packet. The recipient of this
notification MAY compare the supplied value to a hash of the
source IP address and port and if they don't match it MAY
invoke NAT specific handling (like using UDP encapsulation
of ESP packets and subsequent IKE packets). Alternately, it
MAY reject the connection attempt if NAT traversal is not
supported.
NAT_DETECTION_DESTINATION_IP 24583
This notification is used to by its recipient to determine
whether it is behind a NAT box. The data associated with
this notification is a SHA-1 digest of the SPIs, IP address
and port to which this packet was sent. The recipient of
this notification MAY compare the supplied value to a hash
of the destination IP address and port and if they don't
match it MAY invoke NAT specific handling (like using UDP
encapsulation of ESP packets and subsequent IKE packets).
Alternately, it MAY reject the connection attempt if NAT
traversal is not supported.
into:
NAT_DETECTION_SOURCE_IP 24582
This notification is used to by its recipient to determine
whether the source is behind a NAT box. The data associated
with this notification is a SHA-1 digest of the SPIs, IP
address and port on which this packet was sent. There MAY
be multiple notify payloads of this type in a message if the
sender does not know which of several network attachments
will be used to send the packet. The recipient of this
notification MUST compare the supplied value to a hash of the
source IP address and port and if they don't match it MUST
invoke NAT specific handling (like using UDP encapsulation
of ESP packets and subsequent IKE packets). Alternately, it
MUST reject the connection attempt if NAT traversal support
is not enabled.
NAT_DETECTION_DESTINATION_IP 24583
This notification is used to by its recipient to determine
whether it is behind a NAT box. The data associated with
this notification is a SHA-1 digest of the SPIs, IP address
and port to which this packet was sent. The recipient of
this notification MUST compare the supplied value to a hash
of the destination IP address and port and if they don't
match it MUST invoke NAT specific handling (like using UDP
encapsulation of ESP packets and subsequent IKE packets).
Alternately, it MUST reject the connection attempt if NAT
traversal support is not enabled.
(13) In Acknowledgements (7-) the first name of J. Ioannidis is John.
Reingold's one is missing too.
(14) Non-normative References (8.2-) has to out of the style author
references for [LDAP] and [RADIUS]
(15) in H.6 (Change History) s/ala carte/a la carte/ and please
insert a blank line at the end before Editor's Address.
Thanks
Francis.Dupont@enst-bretagne.fr
PS: I have major concerns (i.e., not little details to fix) about
2.11 (Address and Port Agility) and 2.23 (NAT Traversal). I have
to specify two new notifications to protect peer addresses when
NAT traversal is not active (cf draft-dupont-ikev2-addrmgmt-02.txt
where one can find the peer address update payload too).