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

From: Tero Kivinen <[email-masked]>
Date: Thu, 13 Mar 2003 00:54:25 +0200

> 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
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Tue, 18 Mar 2003 22:52:09 +0100

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

=> I am not convinced by this "immediately" and this has an impact on
legacy authentication or other stuff which add messages to the IKE_AUTH
"exchange".

   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

=> same concern.

   (especially if
   
=> I don't buy this. IMHO the only constraint is NAT must be detected
before the IPsec SAs are used. But used != negociated.
With implicit peer address update, the NAT detection can be done in IKE_AUTH
and the switch to UDP 4500 performed only after IKE_AUTH. There are many
advantages to keep same addresses and ports in all messages of the initial
phase.

   
=> I agree (on both points).

=> good comment.

   I.e something like this:

=> this generic rule is not enough clear in the current document.

=> so you should agree that the asymmetry of the current draft is bad,
i.e., the responder cannot be behind the NAT box. My proposal has
not this problem...

=> It seems we share some concerns about the current text about
NAT traversal (:-).

=> it would be fine to use the "peer address" term.

=> this is another example of missing text in the current draft.

=> there are many types of keepalives. You should be more accurate,
for instance "UDP keepalives cannot ...".

=> IKE messages are authenticated if they run over the IKE SA

=> s/ESP/IPsec/

        or the port has changed.

=> in fact it is enough to get a valid (known SPI, authenticated) IPsec
or IKE packet.

   								    ^^^

=> s/supported/& or enabled/ and I am in favor of MUSTs.
Note we have a conflict about the term "enable", I propose
for your usage the term activate ?

=> s/SHOULD/MUST/ ?

   and replace with this:
   
=> same comment.

=> s/should/SHOULD/ ?

   
=> I agree!

   
=> fine. It seems you share my argument that the implicit peer address
update mechanism is the best defense against a rogue NAT.

Thanks

[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 19 Mar 2003 01:00:56 +0200

> legacy authentication or other stuff which add messages to the IKE_AUTH

I think the easiest place to switch to port 4500 is after hte
IKE_SA_INIT packets, i.e when sending the first IKE_AUTH packets. 

> and the switch to UDP 4500 performed only after IKE_AUTH.

There are going to be implementations, that are not supporting the
implicit peer address updates, and for them the state machine goes
much easier if they can store the used address and port from the
IKE_AUTH packet, than to wait for the next UDP enacpsulated packet
after IKE_AUTH.

Also note, that if we switch port after IKE_AUTH, then the responder
CANNOT initiate any exchanges before the responder either initiates
another IKE exchange on new port or sends UDP encapsulated ESP packet.
This would cause wierd problems in such cases. It cannot use the port
500, as there is no keepalives for that port, thus the NAT mapping
goes away quite quickly. 

> There are many advantages to keep same addresses and ports in all
> messages of the initial phase.

For the responder side it does not matter, it will reply back to the
same address where the packet came in. Also when the IKE_AUTH is
finished it can store the last address and port used, and associate
them to the IKE SA so, when it needs remote peer address it can use
them directly.

For the initiator it is also quite easy, simply switch the source and
destination port to 4500 when it detects NAT, and use them from that
on. 

> i.e., the responder cannot be behind the NAT box.

The responder can be behind NAT, but in such case the initiator needs
to find the external address of the NAT box to start the exchange in
first place. Also the NAT must normally be kind of static NAT.

> for instance "UDP keepalives cannot ...".

I am talking about the keepalives defined in the UDP encapsulation
draft. 

>         encapsulated ESP packet can be used to detect that the IP address

The current NAT traversal does NOT support AH, thus only UDP
encapsulation of ESP packets is defined. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Wed, 19 Mar 2003 02:44:56 +0100

=> perhaps it is too easy:
 - it is less secure than at the end of IKE_AUTH
 - it doesn't work if the responder is behind a NAT
 - it doesn't work if the responder doesn't implement NAT-T
   (i.e., if it is not ready to receive packets on UDP 4500)
 - the detection is made only by the initiator
etc.

   There are going to be implementations, that are not supporting the
   implicit peer address updates,

=> I recognize I assume peer address updates are a mandatory part of NAT-T.

   and for them the state machine goes
   much easier if they can store the used address and port from the
   IKE_AUTH packet, than to wait for the next UDP enacpsulated packet
   after IKE_AUTH.

=> in my proposal, the node behind the NAT (usually the initiator but
this is not necessary) must send a packet as soon as SAs are up.
If IKE is trigger by some traffic, this traffic will do the job...
In another cases, IMHO the best is to send an IKE keepalive.

=> it does matter if it wants to protect itself against attacks using
a spoofed source peer address.

=> the last statement is exactly the implicit peer address update
mechanism viewed by IKE, i.e., for the IKE SA.

=> and what happens if the responder is behind the NAT? You assume
the mapping is the same of ports 500 and 4500.

   
=> this is less general, i.e., we should find real world cases where
it doesn't work.

   
=> I know but I can't say the same thing for a random reader.

=> and IPCOMP? There is no reason to restrict to ESP here.

Thanks

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 19 Mar 2003 04:57:50 +0200

>  - it is less secure than at the end of IKE_AUTH

Can you explain why (except that sending the discovery notifications
in clear text packet)?

>  - it doesn't work if the responder is behind a NAT

It should work fine in that case too. There is nothing special
whichever end is behind NAT. Initiator will detect if either end is
behind NAT and will then switch to new port and if the responder is
behind NAT it must either be statically configured NAT (i.e both port
500 and 4500 going to that machine behind NAT), or initiator found out
the address of the other end from some directory service and in that
case it should also put in bit saying that it is behind NAT, and the
initiator should start with port 4500 directly.

>    (i.e., if it is not ready to receive packets on UDP 4500)

If it does not support NAT-T then there is nothing we can do if there
is NAT between. 

>  - the detection is made only by the initiator

No, both ends will know which ends are behind NAT after the
IKE_SA_INIT. 

> this is not necessary) must send a packet as soon as SAs are up.

This complicates the state machine more...

> a spoofed source peer address.

It has nothing to do with NAT-T, the responder must reply back to the
address where the packet was requested anyway, and it should rate
limit replies anyways. 

> the mapping is the same of ports 500 and 4500.

If the machine is behind NAT then there either MUST be statically
configured NAT, and it needs to map both 500 and 4500 to work or it
must be published somewhere and in those cases you can directly say
that this is behind NAT, use port 4500 directly.

> => this is less general, i.e., we should find real world cases where

I do not think there are real world cases where the responder is
behind NAT, especialy dynamic NATs :-)

Static NATs are not a problem as there you just map both 500 and 4500. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Wed, 19 Mar 2003 06:35:04 +0100

=> this is a reason but there are others, for instance the NAT detection
is in fact done on only one message, the reply of IKE_SA_INIT: you can't
perform a three way handshake or with other words a return routability
check.

   
=> so you loose all the other cases (with peer-to-peer, we can see some
support for the case where both ends are behind NATs for instance) and
more you assume a MUST for NAT traversal support (for the start with port
4500). You should make this last point clearer.

   
=> I disagree: either we give a way to manage the failure, or we enforce
NAT-T support (i.e., put a MUST for its support).

   
=> both will know but only the initiator does something with this
knowledge. IMHO this is an unecessary asymmetry.

   
=> this is a matter of taste.

   
=> I disagree: defense against DoS is far easier when DoS packets can be
distinguished from valid packets.

   
=> I can imagine as many as you are ready to read (:-), for instance
one can use some kind of callback mechanism in order to enforce the
side of the initiator (firewalls are good reasons to do that).
To summarize, I can't see why we refuse the opportunity to support
any position for the NAT.

Thanks

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 19 Mar 2003 18:55:34 +0200

> => I can imagine as many as you are ready to read (:-), for instance

I can imagine lots of things, but that does not make it real world
case. 

> side of the initiator (firewalls are good reasons to do that).

Where is that used in real world NOW?

> any position for the NAT.

I do think NAT can be in any position with current draft already, so
there is no need to make the protocol more complicated because of some
imagined cases.

For example the callback mechanism would propably want to do the
initial authentication before calling back, thus in the current
protocol the original responder will already know the mapping for the
port 4500, and there are NAT keepalives already going for that port,
so it can directly connect to that port and use that as callback
address. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Mar 2003 01:45:49 +0100

=> I believe I've got one real world example: peer-to-peer stuff
where both peers can be behind a NAT and confidentiality should be
supported end-to-end. There is a rendezvous system in order to
"configure" the NATs but it doesn't participate to peer-to-peer
communications...
Note that I believe in this case IKE should be run directly over
UDP 4500 and in the unlikely case there is no NAT at all peers
should (in order to avoid a bidding down attack) fallback (i.e.,
retry as soon as they detect no NATs) to UDP 500.
So the rendezvous system should deal with UDP 4500 and a large
part of NAT-T MUST be supported (this is a good argument for
a MUST).

   
=> I've seen this kind of mechanisms for firewall traversal (usually
the rules are very different in the two ways).

   
=> IMHO the current draft is a bit underspecified, for instance it
should explicitely permit to run IKE over port 4500 from the beginning
(so there will be only one mapping and as soon as an exchange succeed
the whole stuff, including IPsec SAs, works).

=> I disagree: a property of the callback is to use the asymmetry
of some IKE features (cf the privacy reopen stuff) in the convenient
way. So let just support any position for NATs: no NAT, initiator
behind a NAT, responder behind a NAT, both peers behind NATs.
With careful wording this should be possible.

=> note you explicitely use an IKE which always runs over UDP 4500.
IMHO this is the good solution and it should be documented (current
draft suggests the first exchange must be over UDP 500).

Thanks

PS: so in your part (NAT-T) you should add some words about IKE_SA_INIT
over UDP 4500 and what to do if no NAT is detected:
 - switch to UDP 500 for next messages (i.e., the opposite of
   NAT detection)
 - continue on UDP 4500 with a possible bidding down attack because
   NAT-T is less efficient (note it is no more less secure because
   the implicit update MUST NOT be enabled when the other peer is
   not behind a NAT, does the extra overhead really matter?)
I propose to give the choice to the initiator with the first one by default?
You should add something for the case all NATs are removed (i.e., an
implicit update to the real peer addresses) with the same tradeoff.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 20 Mar 2003 20:00:50 +0200

> the whole stuff, including IPsec SAs, works).

From the draft-ietf-ipsec-ikev2-05.tx:
----------------------------------------------------------------------
2.11 Address and Port Agility

   IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
   AH associations for the same IP addresses it runs over. The IP
   addresses and ports in the outer header are, however, not themselves
   cryptographically protected, and IKE is designed to work even through
   Network Address Translation (NAT) boxes. An implementation MUST
   accept incoming connection requests even if not received from UDP
   port 500 or 4500, and MUST respond to the address and port from which
   the request was received.  IKE functions identically over IPv4 or
   IPv6.
----------------------------------------------------------------------

I.e it now already says that both port 500 and 4500 are used, and the
NAT traversal sections says:
----------------------------------------------------------------------
2.23 NAT Traversal

...

> draft suggests the first exchange must be over UDP 500).

Where does it say so? The current draft talks about ports 500 and
4500 in almost equal way (only difference being that 4500 have
different encoding and that port 4500 works better through NATs). 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Mar 2003 19:50:24 +0100

=> IMHO this section is too short but this is not the best place for
my "explicitely permit to run IKE over port 4500 from the beginning".

=> but it suggest the NAT Traversal is activated only after a NAT
detection on port 500. I believe we need more flexibility.

   ...

=> with my (current) proposal, this "optional" doesn't make sense so
we can put more in requirements for any implementations or jump
to a SHOULD for NAT Traversal support?

   

=> the current spec describes a switch to port 4500, so implicitely
it assumes it always starts over port 500. This is only a problem
in the wording but it has an impact on the NAT Traversal support
requirement because with the better wording IKE will always support
NAT Traversal and it doesn't make sense to get no support for the
other parts of IPsec. So we can argue for at least a SHOULD based
on a protocol argument.
I'm trying to do several things at the same time so I forget the
most important: places are near NAT-DETECTION words.

Thanks