Hi Tero, thanks for reviewing the draft.
> 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. OK, will remove it. > -- > > 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 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). > 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. 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. > -- > > 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? OK, will add a reference to 10.5. Regards, Valery. > > [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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
