[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft-ietf-ipsec-ikev2-05.txt comments



> 1.4 The INFORMATIONAL Exchange
...
>    A node SHOULD regard half open connections as anomalous and audit

I think we should talk about half closed connections instead of half
open. 

> 2.8 Rekeying
...
>    If the two ends have the same lifetime policies, it is possible that
>    both will initiate a rekeying at the same time (which will result in
>    redundant SAs). To reduce the probability of this happening, the
>    timing of rekeying requests SHOULD be jittered (delayed by a random
>    amount of time after the need for rekeying is noticed).
> 
>    This form of rekeying may temporarily result in multiple similar SAs
>    between the same pairs of nodes. When there are two SAs eligible to
>    receive packets, a node MUST accept incoming packets through either
>    SA. An endpoint SHOULD wait a random amount of time before closing a
>    redundant SA to prevent cycling.

Which one is redundant? What if both ends happen to select different
SAs and destroy them at the same time? Or is it enough to have random
wait and assume that only one of them will be destroyed and if both
are destroyed then both ends will start creating the IPsec SA again
when they want to send next packet. 

> 2.9 Traffic Selector Negotiation
... 
>    To enable Bob to choose the appropriate range in this case, if Alice
>    has initiated the SA due to a data packet, Alice MAY include as the
						      ^^^

I think that should be SHOULD. I.e if there is data packet put the
first TS matching to it. If there is no data packet then you can leave
it out. 

>    first traffic selector in each of TSi and TSr a very specific traffic
>    selector including the addresses in the packet triggering the
>    request. In the example, Alice would include in TSi two traffic
>    selectors: the first containing the address range (10.2.16.43 -
>    10.2.16.43) and the source port and protocol from the packet and the
>    second containing (10.2.16.0 - 10.2.16.255) with all ports and
>    protocols. She would similarly include two traffic selectors in TSr.
...
> 2.15 Authentication of the IKE-SA
...
>    Optionally, messages 3 and 4 MAY include a certificate, or
>    certificate chain providing evidence that the key used to compute a
>    digital signature belongs to the name in the ID payload. The
>    signature or MAC will be computed using algorithms dictated by the
>    type of key used by the signer, an RSA-signed PKCS1-padded-hash for
								^^^^
I assume this is the negotiatiated hash algorithm like it was in the
IKEv1? 

>    an RSA digital signature, a DSS-signed SHA1-hash for a DSA digital
>    signature, or the negotiated PRF function for a pre-shared key.
...
> 2.16 Extended Authentication Protocol Methods
...
>    The Initiator of an IKE-SA using EAP SHOULD be capable of extending
>    the initial protocol exchange to at least ten IKE_AUTH exchanges in
>    the event the Responder sends notification messages and/or retries
>    the authentication prompt. The protocol terminates when the Responder
>    sends the Initiator and EAP payload containing either a success or
			 ^^^
typo.
     
>    failure type.
...
> 2.19 Requesting an internal address on a remote network
...
>    This function provides address allocation to an IRAC trying to tunnel
>    into a network protected by an IRAS.  Since the IKE_AUTH exchange
>    creates an IKE-SA and a CHILD-SA the IRAC MUST request the internal
>    address, and optionally other information concerning the internal
>    network, in the IKE_AUTH exchange.  The may IRAS procure an internal
					 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
???

> 2.23 NAT Traversal
> 
>    NAT (Network Address Translation) gateways are a controversial
>    subject.  This appendix briefly describes what they are and how they
	            ^^^^^^^^
section

...
>    Port 4500 is reserved for UDP encapsulated ESP, AH, and IKE.  When
>    working through a NAT, it is generally better to pass IKE packets
>    over port 4500 because some older NATs modify IKE traffic on port 500
>    in an attempt to transparently establish IPsec connections. Such NATs
>    may interfere with the straightforward NAT traversal envisioned by
>    this document, so an IPsec endpoint that discovers a NAT between it
>    and its correspondent SHOULD send all subsequent traffic to and from
			   ^^^^^^

MUST

The NAT-T protocol does not work with current NAT boxes if you try to
run it over port 500. We must change the port from the 500 to 4500
immediately when we detect NAT. Also the NAT-DETECTION-SOURCE-IP and
NAT-DETECTION-DESTINATION-IP must be in the first two packets, so we
can detect NAT before we start negotiating the child SA (especially if
we want to add the ORIGINAL-ADDRESS notification or similar to support
transport mode ESP). 

>    port 4500, which all NATs should know run the NAT-friendly protocol.
> 
>    The specific requirements for supporting NAT traversal are listed
>    below.  Support for NAT traversal is optional. In this section only,
>    requirements listed as MUST only apply to implementations supporting
>    NAT.
     ^^^

"NAT traversal".

>       IKE MUST listen on port 4500 as well as port 500. IKE MUST respond
>       to the IP address and port from which packets arrived.
> 
>       The IKE responder MUST include in its IKE_SA_INIT response Notify
>       payloads of type NAT-DETECTION-SOURCE-IP and NAT-DETECTION-
>       DESTINATION-IP. The IKE initiator MUST check these payloads if
>       present and if they do not match the addresses in the outer packet
>       MUST tunnel all future IKE, ESP, and AH packets associated with
>       this IKE-SA over UDP port 4500.

I assume that this means that we do not negotiate the UDP-tunnel or
UDP-transport mode as in IKEv1? This is fine with me, but I think we
need some more text here to say so.

Also we need some references to how to actually encapsulate the ESP
packets etc. We also need to specify better how to detect which side
is behind NAT (the UDP encapsulation protocol needs that information
to enabled keepalives only from the host behind NAT, and the IKE needs
that to enable implicit port updating if and only if the other end is
behind NAT (it MUST NOT be enabled if the other end is not behind
NAT)).

I.e something like this:
----------------------------------------------------------------------
        The IKE responder MUST include in its IKE_SA_INIT response
        Notify payloads of type NAT-DETECTION-SOURCE-IP and
        NAT-DETECTION- DESTINATION-IP. The IKE initiator MUST check
        these payloads if present and if they do not match the
        addresses in the outer packet MUST switch to port 4500 for the
        IKE traffic and all IPsec SAs traffic (ESP packets) MUST use
        the UDP encapsulation over port 4500 as defined in the
        [Hutt02].

	The changing to port 4500 MUST happen immediately after
	IKE_SA_INIT exchange, i.e IKE_AUTH payloads are sent with port
	4500 (the reply to IKE_SA_INIT must come back to port 500, as
	specified by generic rule that reply back to address where you
	got the packet, and also because the mapping for the port 4500
	is not yet open in the NAT box, i.e the first packet must come
	from the inside). 

	The purpose of NAT-DETECTION-SOURCE-IP and
	NAT-DETECTION-DESTINATION-IP notifications is twofold, It not
	only detects the presence of NAT between two IKE peers, it
	also detects where the NAT is. The location of the NAT device
	is important in that the keepalives need to initiate from the
	peer "behind" the NAT, and also so that implicit address
	updating is only enabled if and only if the other end is
	behind NAT.

	If the host detects it is behind the NAT, it should start
	sending keepalives as defined in the  [Hutt02].

	If the host detects that the other end is behind the NAT, then
	it SHOULD enable the implicit address updating for the other
	end, i.e if the any authenticated packet from the other end
	(IKE, UDP encapsulated ESP) is received whose source IP
	address and/or port is changed the other ends addresses for
	that IKE SA should be changed to that address (that address is
	used to when sending UDP encapsulated ESP packets to the other
	end and also for future rekeying and notifications).

2.24 NAT Traversal Implicit Address Updating

     There are cases where NAT box decides to remove mappings that are
     still alive (for example, the keepalive interval is too long, or
     the NAT box is rebooted). To recover from those hosts which are
     NOT behind NAT SHOULD use the last valid authenticated packet
     from the other end to determine which IP and port addresses
     should be used. The host behind dynamic NAT MUST NOT do this as
     otherwise it opens DoS attack possibility, and there is no need
     for that, because the IP address or port of other host will not
     change (it is not behind NAT).

     Keepalives cannot be used for this purposes as they are not
     authenticated, but any IKE authenticated IKE packet or UDP
     encapsulated ESP packet can be used to detect that the IP address
     or the port has changed.
----------------------------------------------------------------------

...
>       All implementations of IKEv2 MUST include a management facility
>       that enables a user or system administratror to specify the Suite
>       IDs that are acceptable for use with IKE. Upon receipt of a
>       payload with a suite ID, the implementation must compare the
>       transmitted suite ID against those locally configured via the
>       management controls, to verify that the proposed suite is
>       acceptable based on local policy.  The implementation MUST reject
>       key exchange payloads that are not authorized by these IKE suite
	^^^^^^^^^^^^

"securety association payloads"?

> 3.4 Key Exchange Payload
> 
>    The Key Exchange Payload, denoted KE in this memo, is used to
>    exchange Diffie-Hellman public numbers as part of a Diffie-Hellman
>    key exchange.  The Key Exchange Payload consists of the IKE generic
>    header followed by the Diffie-Hellman public value itself.
> 
>                            1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       ! Next Payload  !C!  RESERVED   !         Payload Length        !
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       !            Suite-ID           !       RESERVED (MBZ)          !
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I do not really understand why do we have still these "RESERVED (MBZ)"
fields here? They cannot be here for the alignment purposes because
previous packets might not be aligned, thus the packet can be
unaligned anyways. I actually think we should remove those which are
not because of the IKEv1 compatibility (i.e Key exchange payload, auth
payload, traffic selectors, configuration payload). 

> 3.7 Certificate Request Payload
...
>    Empty (zero length) CA names MUST NOT be generated and SHOULD be
>    ignored.

This has already been talked earlier, nothing more now...

...
>    While intended to allow for future expansion, the only form of
>    certificate request currently defined is X.509 signing certificate
>    (4). For that type, the CA value is a concatenated list of SHA-1
>    hashes of the public keys of trusted root CAs.

How about type 11 (Raw RSA key)? I think it would be useful to send
certificate request payload for type 11, and leave the contents empty
(as it really does not matter).

And types 1 (PKCS 7), 7 (CRL), 8 (ARL), 12, and 13 (Hash and URL
types) should have same format as type 4.

> 3.10 Notify Payload
...
>    o  Protocol-Id (1 octet) - Specifies the protocol about which
>       this notification is being sent. For IKE-SA notifications,
>       this field MUST be zero (0). For notifications
>       concerning IPsec SAs this field will contain either (1)
>       to indicate ESP or (2) to indicate AH. For notifications
>       for which no protocol ID is relevant, this field MUST be
>       sent as zero and MUST be ignored.

This is different, that what was used in the IKEv1. I think this
should be mentioned in the appendix A (the payload looks same, but it
isn't).

> 3.10.1 Notify Message Types
... 
>         INVALID-MESSAGE-ID                        9
> 
>             Sent when an IKE MESSAGE-ID outside the supported window is
>             received.  This Notify MUST NOT be sent in a response; the
>             invalid request MUST NOT be acknowledged.  Instead, inform
>             the other side by initiating an INFORMATIONAL exchange with
>             Notification data containing the four octet invalid MESSAGE-
>             ID. Sending this notification is optional, MUST be rate
>             limited, and MUST NOT be sent unless an IKE-SA exists to the
>             sending address and port.

How can you get invalid message-id if you do not have IKE-SA, as the
message id is property of the IKE-SA?

Remove the ", and MUST NOT be sent unless an IKE-SA exists to the
sending address and port.". 

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

From the "The recipient of this notification ..." change to this:
----------------------------------------------------------------------
	      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 SHOULD enable NAT
	      traversal (see section 2.23). Alternately, it MAY reject
	      the connection attempt if NAT traversal is not
	      supported.

	      If this check fails it means that the other end is
	      behind NAT and this end SHOULD enable the NAT Traversal
	      implicit address updating (see section 2.24).
----------------------------------------------------------------------

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

Again remove this:

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

and replace with this:
----------------------------------------------------------------------
	      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 SHOULD invoke NAT
              traversal (see section 2.23). Alternately, it MAY reject
              the connection attempt if NAT traversal is not
              supported.

	      If this check fails it means that this end is behind NAT
	      and this end should start sending keepalives as defined
	      in the [Hutt02]. 
----------------------------------------------------------------------

The [Hutt02] reference is to the

[Hutt02] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets",
draft-ietf-ipsec-udp-encaps-05.txt, December 2002

> 3.11 Delete Payload
>    o  Protocol-Id (1 octet) - Must be zero for an IKE-SA, 1 for
>       ESP, or 2 for AH.

Again different from IKEv1.

> 3.13 Traffic Selector Payload
...
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       ! Next Payload  !C!  RESERVED   !         Payload Length        !
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       ! Number of TSs !                 RESERVED                      !
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       !                                                               !
>       ~                       <Traffic Selectors>                     ~
>       !                                                               !
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
>    o  RESERVED - This field MUST be sent as zero and MUST be ignored.

Is there any reason for this reserved?

> 3.13.1 Traffic Selector
...
>    The following table lists the assigned values for the Traffic
>    Selector Type field and the corresponding Address Selector Data.
> 
>       TS Type                           Value
>       -------                           -----
>       RESERVED                            0
> 
>       TS_IPV4_ADDR_RANGE                  7
>       TS_IPV6_ADDR_RANGE                  8

As this is new payload, I see no use to try to reuse the numbers from
the old identity type values. I think it is better to create new
repository and renumber these to 1 and 2. 

> 3.15.1 Configuration Attributes
...
>                                       Multi-
>         Attribute Type          Value Valued Length
>         ======================= ===== ====== ==================
>          INTERNAL_IP4_SUBNET     13    NO    0 or 8 octets
>          INTERNAL_IP6_SUBNET     15    NO    17 octets

I think those two should be multi-valued, at least the description
later indicates that there might be multiple subnets behind (at least
you can request multiple subnets). 

>       o  INTERNAL_IP4_SUBNET - The protected sub-networks that this
>          edge-device protects.  This attribute is made up of two fields;
>          the first being an IP address and the second being a netmask.
>          Multiple sub-networks MAY be requested.  The responder MAY
>          respond with zero or more sub-network attributes.
...
>       o  INTERNAL_IP6_SUBNET - The protected sub-networks that this
>          edge-device protects.  This attribute is made up of two fields;
>          the first being a 16 octet IPv6 address the second being a one
>          octet prefix-mask as defined in [ADDRIPV6].  Multiple
>          sub-networks MAY be requested.  The responder MAY respond with
>          zero or more sub-network attributes.

> 5 Security Considerations

The NAT traversal needs some more entries here (copied from
draft-ietf-ipsec-nat-t-ike-05):

----------------------------------------------------------------------
As the internal address space is only 32 bits, and it is usually very
sparse, it might be possible for the attacker to find out the internal
address used behind the NAT box by trying all possible IP-addresses
and trying to find the matching hash. The port numbers are normally
fixed to 500, and the SPIs can be extracted from the packet. This
limits the hash calculations down to 2^32. If educated guess of use of
private address space is done, then the number of hash calculations
needed to find out the internal IP address goes down to the 2^24 + 2 *
(2^16).

Updating the IKE SA / ESP UDP encapsulation IP addresses and ports for
each valid authenticated packet can cause DoS in case we have attacker
who can listen all traffic in the network, and can change the order of
the packet and inject new packets before the packet he has already
seen. I.e attacker can take the authenticated packet from the host
behind NAT, change the packet UDP source or destination ports or IP
addresses and sent it out to the other end before the real packet
reaches there. The host not behind the NAT will update its IP address
and port mapping and sends further traffic to wrong host or port. This
situation is fixed immediately when the attacker stops modifying the
packets as the first real packet will fix the situation back to
normal. Implementations SHOULD AUDIT the event every time the mapping
is changed, as in normal case it should not happen that often.

> 7 Acknowledgements
> 8 References

I think we need the section "Intellectual property rights" section
because of the NAT traversal.
----------------------------------------------------------------------
7.  Intellectual property rights

The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this document.
For more information consult the online list of claimed rights.
----------------------------------------------------------------------

> Appendix B: Diffie-Hellman Groups
> B.1 Group 1 - 768 Bit MODP

As there is no suite id allocated for this group, I think it should be
removed from this document. If someone wants to use this group (i.e
create new suite id), they can reference it from the RFC2409.

> B.2 Group 2 - 1024 Bit MODP
> B.3 Group 3 - 155 Bit EC2N
> B.4 Group 4 - 185 Bit EC2N

Same goes for groups 3 and 4. They are not used, so why are they added
here. 

> B.5 Group 5 - 1536 Bit MODP
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/