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. > 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
