[IPsec] My comments to draft-ietf-ipsecme-ike-tcp-01.txt

[Tero Kivinen <[e-mail]>]

Ok, got finally to continue my IPsec work. Here are my comments to the
draft (next is advpn, but not sure whether I will be able to read it
before xmas):

----------------------------------------------------------------------
1.1.  Non-Goals of this Specification

   Firewall traversal is not a goal of this specification.  If a


Add

	(except when bypassing broken firewall dropping all framents)

I think that is one of the goals. I.e. goal is not to bypass policy
rules, goals is to fix brokeness caused by broken implementations not
supporting fragments.

----------------------------------------------------------------------
2.1.  Initiator
...
   An initiator MUST accept responses sent over IKE within the same
   connection, but MUST also accept responses over other transports, if
   the request had been sent over them as well.

What that "sent over IKE" is supposed to mean, TCP/UDP? Any protocol?
----------------------------------------------------------------------
2.4.  Receiver
...
   the same way as regular UDP messages.  That includes retransmission
   detection, with one slight difference: if a retransmitted request is
   detected, the response is retransmitted as well, but using the
   current TCP connection rather than whatever other transport had been
   used for the original transmission of the request.

What does this mean with MOBIKE. For example the UPDATE_SA_ADDRESSES
notify assumes the address which should be used is taken from the
current IP header (IP and port), but if the message is retransmitted
over TCP this messes up things (port is different if there is NAT).
Easiest way would say that such UPDATE_SA_ADDRESSES notification over
TCP is replied, but ignored, i.e. it does not cause any actual MOBIKE
change. We cannot really do the change, as we do not know the UDP port
number in case the initiator sending UPDATE_SA_ADDRESSES is behind
NAT. Also with MOBIKE that will disable the dynamic port update
happening with normal IKEv2, so all UDP port changes only happen with
UPDATE_SA_ADDESSES.

Other option is to reply with UNACCEPTABLE_ADDRESSES error to all
MOBIKE UPDATE_SA_ADDRESSES requests coming over TCP, in which case it
is clear for sender of UPDATE_SA_ADDRESSES thta it failed, but it
should also be clear for sender of the request that it retried it over
TCP, so it should be able to ignore it in that case too..

Actually the whole behavior with the MOBIKE is missing. I.e. do we
first try with UDP then with TCP, and if that fails, then try other IP
addresses, or do we first try with all IP addresses with MOBIKE and
then fall back to TCP.

I think it should most likely try with TCP only if the packet we are
trying to send is big i.e > 500 bytes, and if the packet we are trying
to send is small then we should first try all possible IP addresses,
and if that fails then go to TCP.

If packet is big, we should first try with TCP over the current IP
address, and if that does not work, then fall back to normal MOBIKE
processing. 

----------------------------------------------------------------------
4.  Security Considerations

   Most of the security considerations for IKE over TCP are the same as
   those for UDP as in RFC 5996.

   For the Responder, listening to TCP port 500 involves all the risks
   of maintaining any TCP server.  Precautions against DoS attacks, such
   as SYN cookies are RECOMMENDED. see [RFC4987] for details.
   
Actually TCP has much bigger buffering and state requirements than
UDP, especially with the stateless cookies. Syn cookies are not only
attack, any peer can open TCP session to the gateway and start sending
4GB IKE packet... Unless special checks of source IP is done then any
host in the world can do the same.

IKE header length field is 32 bits, so it might be good idea for
implementations to limit this to something suitable... On the other
hand one reason to use TCP would be able to transfer big certfificate
chains or CRL lists, so the limit cannot be too small...
-- 
[e-mail]