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
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
