Subject: [IPsec] Review of the draft-smyslov-ipsecme-rfc8229bis-02

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Feb 2021 16:24:27 +0200

I quickly reviewed the draft-smyslov-ipsecme-rfc8229bis-02, or more
accurately I reviewed the diff between the rfc8229 and this draft [1]

During the review I found this text:

       Additionally, since TCP headers are longer than UDP headers, and TCP 
       encapsulation adds a 16-bit Length field, some very long ESP and IKE 
       messages that could be sent over UDP cannot be encapsulated in TCP, 
       because their total length after encapsulation would exceed 65535 and 
       thus could not be represented in Length field.

In my understanding the length of TCP headers does not matter, as we
just send data inside the TCP stream, thus only "expansion" is the
extra 16-bit Length field and the non-ESP marker for IKE messages.
This means the inner ESP packet can be up to 65535-2 = 65533 octets
long, which is longer that you can put in to the IP packet (which will
need some headers). The maximum IKE packet you can use in TCP is
65535-2-4 = 65529 octets, which is still more than you can put in the
normal IKE UDP packet.

So in general I do not think the text above is true, and I do not
think we should be adding such text.

--

In section 7.3 there is text saying:

   	       	     	     Note that if this TCP connection is 
          closed, the Responder MUST NOT include the Initiator's TCP port 
          into the Cookie calculation (*), since the Cookie will be returned 
          over a new TCP connection with a different port. 

As this is used in situation where UDP does not work reliably which
usually means there are NATs involved, that might also mean that the
TCP source address might also change. So including TCP source address
to the cookie calculation might also cause problems. Also adding those
to the cookie calculations does not help at all, as we do full round
trip exchange to set up the TCP session anyways, so having them there
doesn't really make any difference. This might cause attacker to be
able to get one cookie, solve it once, and send responses over several
TCP connections, but I think responder needs to be able to reject
multiple solutions to same puzzle even when source address and port
are not included in the cookie.

--

In section 7.7 should we also cover what to do with ECN? Ah it is
already described in section 10.5, should there be reference to there
from here?

[1] https://www.ietf.org/rfcdiff?url1=rfc8229&url2=draft-smyslov-ipsecme-rfc8229bis-02
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 25 Feb 2021 17:30:33 +0300

Hi Tero,

thanks for reviewing the draft.

> think we should be adding such text.

OK, will remove it.

Not necessary, it may be just firewall blocking UDP.

> TCP source address might also change. So including TCP source address

Even with NAT source address is less likely to change
(though I didn't say it cannot change).

> are not included in the cookie.

I don't think the responder should keep track of solved puzzles.
At least I don't recall that RFC 8019 contains such a requirement.

Anyway, the situation with IP address is less important,
since in most cases source IP will be the same even with NATs.
Note, that RFC 7296 recommends to include source IP in cookie
calculation, so if it NAT changes it each time it creates
new state (TCP or UDP), then IKEv2 over UDP won't work too.
I think it's a rare situation, so we may ignore it.

OK, will add a reference to 10.5.

Regards,
Valery.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Feb 2021 17:28:18 +0200

> (though I didn't say it cannot change).

With TCP the source address changing is much more common than with
UDP. With UDP the expectation is that source address needs to stay
table, otherwise it does not work. With TCP it is assumed that each
TCP connection is independent and peers should not care what the
address is with two different connections. I.e. http or https does not
care if two connections from the same browser have different source
addresses, everything works just fine. 

> I think it's a rare situation, so we may ignore it.

NATs quite often try to keep the UDP source addresses stable, for
example by mapping each inner IP address to block of UDP addresses on
one IP address. For TCP connections there might not be such setup, it
might just use any outer address it has for different connections.
Especially if the solving of the puzzle takes some time, i.e., you
make one TCP connection, get cookie, and puzzle, and then break TCP
connection, solve puzzle and then reconnect.

With normal RFC7296 cookies, the other end is assumed to be reconnect
so quickly that UDP mapping is still in place. With puzzles this might
not hold true anymore if solving puzzles takes more than tens of
seconds. On the other hand if solving puzzle only takes few seconds,
the UDP mapping is still there. 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 26 Feb 2021 09:15:47 +0300

Hi Tero,

so, what is the outcome? Do you think we should add a recommendation
not to include source IP address in cookie calculation when TCP is in use?

Regards,
Valery.