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