Subject: [IPsec] Comments to draft-ietf-ipsecme-ike-tcp-00.txt

From: Tero Kivinen <[email-masked]>
Date: Sun, 4 Nov 2012 03:51:45 +0200

In the section 1 there is text:

----------------------------------------------------------------------
		  Specifically, the messages of the IKE_AUTH
   exchange can become quite large, as they may contain a chain of
   certificates, an "Auth" payload (that may contain a public key
   signature), CRLs, and some configuration information that is
   carried in the CFG payload.
----------------------------------------------------------------------

In addition to the IKE_AUTH there is another big class of UPD packets
which can be large, and which might get fragmented, i.e udp
encapsulated nat traversal IPsec UDP packets. If the protocol run
inside the transport mode IPsec connection sends large packets they
may get fragmented too. This should not be problem for TCP, as PMTU
should make the packets small enough not to get them fragmented, but
if you run some UDP based application then this might be issue.

For tunnel mode IPsec traffic, the gateway can fragment inner packets
before wrapping them to ESP, so the outer ESP packets visible to nat
box are not fragmented.

Another thing that should be mentioned here that IKEv2 already have
several optional features which will solve the large IKE_AUTH packet
problem: the certificate can be replaced with hash and url format; The
child sa negotiation can be postponed with childless sa exchange
(removes the traffic selectors); Postponing the child sa creation also
allows running the cfg mode exchange can be done as separate
informational exchange (i.e. removing even configuration payloads from
the IKE_AUTH packet); Using elliptic curves instead of RSA will make
auth payload smaller. All these optional features should make the
IKE_AUTH packet to be less than 300 bytes.

I think this document should mention those optional features, as
implementing them allows much more efficient protocol than
transmitting the IKE_AUTH over TCP.

In section "3. Operational Considerations" there is text saying:

----------------------------------------------------------------------

   An alternative method, that is probably easier for the Initiator to
   implement, is to do an entire "mission" using the same transport. So
   if TCP is needed for long messages and an IKE SA has not yet been
   created, the Initiator will open a TCP connection, and perform all
   2-4 requests needed to set up a child SA over the same connection.

----------------------------------------------------------------------

Note, that NAT detection might not work properly, when IKE_SA_INIT is
run over TCP (i.e. over different protocol), especially if IKE_SA_INIT
is first tried with UDP, and then retransmitted over different
protocol. The IKEv2 RFC5996 says that "A retransmission from the
initiator MUST be bitwise identical to the original request." (section
2.1 or RFC5996), which means we cannot modify the NAT_DETECTION_*_IP
payloads when switching from UPD to TCP. This might cause NAT to be
detected even when there is none there (i.e. the UDP source port is
500, but TCP source port is most likely going to be random).

Also I think this document should tell the justifications why the TCP
session is not kept alive all the time, but only created for sending
one packet and then immediately teared down. I assume the idea there
is that open TCP session actually requires quite a lot of resources
from the SGW, i.e. maintaining the send and receive windows requires
tens of kilobytes of memory. Of course the downside of such short TCP
sessions is that sending one exchange over TCP now requires 2 round
trips of delay, and most likely around 10 packets, compared to the 1
round trip and 2 packets.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Nov 2012 12:40:45 -0500

Tero Kivinen <[email-masked]> wrote:
    TK> ----------------------------------------------------------------------
    TK> Specifically, the messages of the IKE_AUTH exchange can become
    TK> quite large, as they may contain a chain of certificates, an
    TK> "Auth" payload (that may contain a public key signature), CRLs,
    TK> and some configuration information that is carried in the CFG
    TK> payload.
    TK> ----------------------------------------------------------------------

    TK> In addition to the IKE_AUTH there is another big class of UPD
    TK> packets which can be large, and which might get fragmented, i.e
    TK> udp encapsulated nat traversal IPsec UDP packets. If the

I don't think you are suggesting any specific technical change to
support this.  I think that you are saying that we need to be more clear
that we aren't proposing anything here.  And that if TCP gets used for
the AUTH payload, that might be a clue to the IPsec layer that it should
do:

    TK> For tunnel mode IPsec traffic, the gateway can fragment inner
    TK> packets before wrapping them to ESP, so the outer ESP packets
    TK> visible to nat box are not fragmented.

which the gateway machine might not otherwise do. But, this can't be
done for IPv6.
(There isn't really any significant downside to doing this.  If
anything, this moves the memory expense of fragment reassembly from
gateways to end nodes.)

    TK> which means we cannot modify the NAT_DETECTION_*_IP payloads
    TK> when switching from UPD to TCP. This might cause NAT to be
    TK> detected even when there is none there (i.e. the UDP source port
    TK> is 500, but TCP source port is most likely going to be random).

The document does not tell us if we have to originate from port-500.
I don't think that we can.

    TK> Also I think this document should tell the justifications why
    TK> the TCP session is not kept alive all the time, but only created
    TK> for sending one packet and then immediately teared down. I
    TK> assume the idea there is that open TCP session actually requires
    TK> quite a lot of resources from the SGW, i.e. maintaining the send
    TK> and receive windows requires tens of kilobytes of memory. Of
    TK> course the downside of such short TCP sessions is that sending
    TK> one exchange over TCP now requires 2 round trips of delay, and
    TK> most likely around 10 packets, compared to the 1 round trip and
    TK> 2 packets.  

Yes.  I think that the congestion window argument is probably not
relevant. I don't think the congestion window will open much even if the
first round trip goes through.   

-- 
Michael Richardson
-on the road-

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 4 Nov 2012 22:25:00 +0200

> the AUTH payload, that might be a clue to the IPsec layer that it should

No, I was just pointing out that IKE_AUTH is not the only packet which
can be big packets, and UDP encapsulated packets might also have
problems bypassing the NATs dropping all fragments. 

> anything, this moves the memory expense of fragment reassembly from

On the other hand I am not sure NAT boxes do drop IPv6 fragments...
IPv6 and NAT are not used that often together.

> I don't think that we can.

I think it says for TCP we use random port, but for UDP the IKEv2
RFC5996 says you use port 500 (but must allow source port to be other
than 500). With TCP there is problems if we try to use source and dest
port of 500 for all requests, as there might still be old connections
waiting for cleanup in the system when we start next one.

> first round trip goes through.   

In most systems just opening the TCP session will reserve 32 kB
buffers for sending and receiving immediately when you open tcp
connection. Earlier that was one of the parameters you needed to tune
down for web servers if you wanted to support lots of clients.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Nov 2012 16:02:29 -0500

>> support this.  I think that you are saying that we need to be
    >> more clear that we aren't proposing anything here.  And that if
    >> TCP gets used for the AUTH payload, that might be a clue to the
    >> IPsec layer that it should do:

    TK> No, I was just pointing out that IKE_AUTH is not the only packet
    TK> which can be big packets, and UDP encapsulated packets might
    TK> also have problems bypassing the NATs dropping all fragments.

So, the converse statement (for me) is that you think that we should
specify a way to carry ESP over TCP.

    >> which the gateway machine might not otherwise do. But, this can't
    >> be done for IPv6.  (There isn't really any significant downside
    >> to doing this.  If anything, this moves the memory expense of
    >> fragment reassembly from gateways to end nodes.)

    TK> On the other hand I am not sure NAT boxes do drop IPv6
    TK> fragments...  IPv6 and NAT are not used that often together.

IPv6 packets inside ESP over IPv4-ESP-UDP.
This gives your laptop ubiquitous IPv6, even when behind stupid networks.

    >> relevant. I don't think the congestion window will open much even
    >> if the first round trip goes through.

    TK> In most systems just opening the TCP session will reserve 32 kB
    TK> buffers for sending and receiving immediately when you open tcp
    TK> connection. Earlier that was one of the parameters you needed to
    TK> tune down for web servers if you wanted to support lots of
    TK> clients.  

yeah, but the concern listed in the document is that the initial
congestion window wouldn't be big enough to quickly send out the large
IKE_AUTH payload.   Having at least one RTT for the initial IKE_INIT
exchange would allow TCP to double the window, and get an estimate for
RTT.

-- 
Michael Richardson
-on the road-