Subject: [Simple] Objects to NATs kill TCP connection

From: Cullen Jennings <[email-masked]>
Date: Sat, 15 Nov 2003 16:31:56 -0800

There was some assertion in the WG meeting that NATs arbitrarily kill TCP
connection and the connection needs to be set up again. I'm sure this has
happened with broken NATS but I do not feel it is widespread and don't think
we should specifically design for it. I do think we should design for
graceful failure or recover when things in the network fail but I don't
think there is a common case of TCP failing that involves NATs. If there
were, many things that do not automatically set up a new TCP connection,
like ssh for example, would be nearly unusable through these broken NATs.

Cullen

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Wed, 19 Nov 2003 13:13:28 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Paul Kyzivat
> Sent: 18.November.2003 21:13
> To: Ben Campbell
> Cc: Jonathan Rosenberg; Cullen Jennings; [email-masked]
> Subject: Re: [Simple] Objects to NATs kill TCP connection
> 
> 
> 
> 
> Ben Campbell wrote:
> > Can we reasonably assume that all connection failures are 
> due to NATs? 
> > What happens if endpoints do this when the failure is caused by 
> > something else?
> 
> Good point. That could be ugly - I don't see any easy way to 
> know when 
> the connection fails because of NAT. Lacking that it seems 
> infeasible to 
> test for the NAT timeout interval.
> 
> Are there any standard practices in this regard? In other words, is 
> there a keepalive time we could use that would be sufficient 
> most of the 
> time and still not be too impractical to keep up?

To be safe, you need a keepalive message every 30 seconds. You can always send empty TCP packets.

Shouldn't this anyway be a relay problem? maybe a BIND is sent to the relay every x seconds.

Regards,
Hisham

> 
> 	Paul
> 
> > Paul Kyzivat wrote:
> > 
> >> Letting msrp keepalives act as NAT binding keepalives seems 
> >> attractive. Perhaps the NAT keepalive time needs to be determined 
> >> adaptively. If the connection is found to be down, a 
> reinvite could 
> >> reconstruct it, and a new keepalive timer could be set, 
> shorter than 
> >> before.
> >>
> >> But this would require negotiating the keepalive time.
> >>
> >>     Paul
> >>
> >> Jonathan Rosenberg wrote:
> >>
> >>> The trick, as always, is knowing what the nat keepalive 
> is. There is 
> >>> no easy way to know.
> >>>
> >>> -Jonathan R.
> >>>
> >>> Ben Campbell wrote:
> >>>
> >>>> When we were having the recent discussion on the 
> inactivity timeout 
> >>>> for MS(R)P, I don't think we thought much about the fact 
> that MSRP 
> >>>> keepalive messages may also act as NAT binding keepalives.
> >>>>
> >>>>
> >>>>
> >>>> Jonathan Rosenberg wrote:
> >>>>
> >>>>> Short timeouts are broken, sure, but the fact that NATs have 
> >>>>> timeouts on bindings is a common behavior. As a result, 
> if there is 
> >>>>> no traffic on the TCP connection before the timeout occurs, the 
> >>>>> binding is lost, and any data sent on that connection will fail.
> >>>>>
> >>>>> Therefore, I think we can expect to see cases where the 
> connections 
> >>>>> close due to NAT.
> >>>>>
> >>>>> Now, the question is, do we think we would see periods of 
> >>>>> inactivity on the messaging will exceed a typical nat 
> timeout? I 
> >>>>> think they may. I personally tend to leave IM sessions open 
> >>>>> continuously all day..
> >>>>>
> >>>>> -Jonathan R.
> >>>>>
> >>>>> Ben Campbell wrote:
> >>>>>
> >>>>>> I have personally encountered this behavior in the 
> wild. I agree, 
> >>>>>> however, that it was broken, and probably not a normal 
> use case. 
> >>>>>> And as far as I know, it pretty much killed anything 
> other than 
> >>>>>> hit-and-run HTTP connections.
> >>>>>>
> >>>>>> Paul Kyzivat wrote:
> >>>>>>
> >>>>>>> Cullen,
> >>>>>>>
> >>>>>>> I don't have any data of my own on this subject, but 
> I hope you 
> >>>>>>> are right.
> >>>>>>>
> >>>>>>> It would be a lot simpler if we can continue to 
> assume that the 
> >>>>>>> way you reestablish an MSRP session is via a reINVITE. The 
> >>>>>>> adequacy of that was under question if NATs regularly 
> blow away 
> >>>>>>> connections.
> >>>>>>>
> >>>>>>>     Paul
> >>>>>>>
> >>>>>>> Cullen Jennings wrote:
> >>>>>>>
> >>>>>>>> There was some assertion in the WG meeting that NATs 
> arbitrarily 
> >>>>>>>> kill TCP
> >>>>>>>> connection and the connection needs to be set up 
> again. I'm sure 
> >>>>>>>> this has
> >>>>>>>> happened with broken NATS but I do not feel it is 
> widespread and 
> >>>>>>>> don't think
> >>>>>>>> graceful failure or recover when things in the 
> network fail but 
> >>>>>>>> I don't
> >>>>>>>> think there is a common case of TCP failing that 
> involves NATs. 
> >>>>>>>> If there

---

From: [email-masked]
Date: Thu, 20 Nov 2003 09:28:38 +0200

> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: 19.November.2003 16:23
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> [email-masked] wrote:
> 
> > 
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>ext Paul Kyzivat
> It can occur without any relays. For example, what if one 
> (the active) 
> endpoint is natted and the other is not? This scenario works 
> with no relays.

We had relays in the protocol to solve such problems of NAT and firewall traversal. Lets not try to solve the problems introduced by NATS and firewalls without relays.

MS(R)P does not support NAT and firewall traversal without relays. Am I missing something?

/Hisham