Hmm, maybe. Or maybe not. Or maybe just ignore it in case of TCP? I think that in general the co-existence of MOBIKE and TCP must be
elaborated in more detail in the draft. I'm having a hard time imagining why anyone would want to use NO_NATS_ALLOWED with TCP encapsulation. If you're encapsulating in TCP it means that there is something on path even worse than a NAT, right? Perhaps we could simply say you MUST NOT use NO_NATS_ALLOWED with TCP encaps? David On Thu, Nov 8, 2018 at 12:07 PM Valery Smyslov <[email protected] <mailto:[email protected]> > wrote: Hi, coming back to the yesterday discussion. There seems to be another issue if implementation first sends request to update address over UDP and then switches to TCP. The problem arises if NO_NATS_ALLOWED is included - it contains IP addresses and ports for initiator and responder. If you leave it intact while switching to TCP, then it won't match real addresses and the responder will treat it as NAT presence. In this case RFC 4555 suggests to retry sending request several times with a new INFORMATIONAL request. Probably we could clarify in TCP guidelines draft that the content of NO_NATS_ALLOWED MUST be recalculated in this case? Or is it obvious? Regards, Valery. _______________________________________________ IPsec mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
