Subject: RE: [Ietf-behave] What to do if a NAT runs out of binding entries?

From: "Francois Audet" <[email-masked]>
Date: Fri, 28 Apr 2006 09:30:14 -0700 (PDT)

This should be in the ICMP draft, right?

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Philip Matthews
> Sent: Friday, April 28, 2006 05:23
> To: Dan Wing
> Cc: 'Behave'
> Subject: Re: [Ietf-behave] What to do if a NAT runs out of 
> binding entries?
> 
> 
> Dan:
> 
> I think that the section you refer to is part of the answer, 
> but not the entire answer.
> 
> That section says that _IF_ the NAT decides to reject an outbound  
> session,
> then it should send an ICMP packet back to the host.
> 
> But consider a NAT that never rejects a new outbound session 
> but simply discards some older session and re-uses its 
> binding entry. Does section 2.3 of 
> draft-srisuresh-behave-nat-icmp-01 apply, since outbound 
> packets are never rejected? By my reading, the answer is NO.
> 
> 
> I feel we need an additional requirement that talks 
> explicitly about the situation when all binding entries are 
> in use and a packet arrives that would create a new outbound session.
> 
> My suggestion for the behavior in this situation is to say:
>      The new session is rejected. An ICMP reply is generated back
>      to the host (as described in draft-srisuresh-behave-nat-icmp-01).
> Under this suggestion, the only way a NAT terminates an 
> outbound UDP session is when it times out.
> 
> Note that I am open to other proposals for how to handle this 
> situation, as long as the proposal gives a NAT behavior that 
> an application can work with.
> 
> - Philip
> 
> 
> 
> On 27-Apr-06, at 18:24 , Dan Wing wrote:
> 
> > Philip,
> >
> > Would section 2.3 of 
> draft-srisuresh-behave-nat-icmp-01.txt, or text 
> > very similar to it, satisfy your need?  The authors, 
> chairs, and a few 
> > others have had a long offline discussion about that ICMP message.
> >
> > -d
> >
> >
> >> -----Original Message-----
> >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf 
> Of Philip 
> >> Matthews
> >> Sent: Thursday, April 27, 2006 9:33 AM
> >> To: Behave
> >> Subject: [Ietf-behave] What to do if a NAT runs out of binding 
> >> entries?
> >>
> >> The current discussion on the timeout value for a UDP binding 
> >> connection is closely related to a question I brought up 
> during the 
> >> last WG meeting
> >> in Dallas:
> >>
> >>       What should a NAT do if it receives a UDP packet (on the 
> >> private side
> >>       of the NAT) with a new source (address,port) combination and 
> >> all its
> >>       binding entries are in use?
> >>
> >> As a P2P application designer, I would like NATs to behave in some 
> >> deterministic and helpful manner when faced with this situation.
> >>
> >> My guess is that most NATs today, when faced with this situation, 
> >> pick some existing binding, discard it, and then used the 
> freed entry 
> >> for the new packet.
> >>
> >> Think for a minute how this behavior appears to the P2P 
> application 
> >> which is sending keep-alives on all its  connections at the 
> >> appropriate interval
> >> (every 1 minutes, 2 minutes, or whatever we decide).
> >> Its connections seem VERY UNRELIABLE.
> >> The application can always send UDP packets, but incoming 
> UDP packets
> >> on that connection will get mysteriously dropped if the
> >> binding entry
> >> for
> >> that connection was one that got re-used by the NAT for some other
> >> purpose.
> >> However, the connection will be re-established (at least 
> temporarily)
> >> whenever the applications sends the next keep-alive.
> >>
> >> My suggestion is that NATs should implement the following behavior:
> >>
> >>      If a NAT receives a UDP packet (on the private side 
> of the NAT)
> >>      with a new source (address,port) combination and all 
> its binding
> >>      entries are in use, then the UDP packet is dropped and an ICMP
> >>      reply sent back.
> >>
> >> This would give deterministic behavior to applications. A P2P 
> >> application would know that, if it succeeds in establishing the
> >> connection, then the
> >> connection will stay up if the necessary keep-alives are sent.
> >>
> >> Any comments?
> >> Especially from folks implementing NATs?
> >>
> >> - Philip
> >>
> >>
> >>
> >>
> >> - Philip
> >> _______________________________________________
> >> Ietf-behave mailing list
> >> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> >> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 28 Apr 2006 10:45:55 -0700 (PDT)

Is this situation specific to UDP? I think this is common to both UDP
and TCP. However, I agree with you that NAT should behave in a
deterministic fashion in this scenario and it should not randomly pick a
mapping to remove. But I think the requirement should reside in the ICMP
draft or in a generic draft that is common to both TCP and UDP.

Senthil

> Sent: Friday, April 28, 2006 8:23 AM
> To: Dan Wing (dwing)
> Cc: 'Behave'
> That section says that _IF_ the NAT decides to reject an 
> outbound session, then it should send an ICMP packet back to the host.
> 
> but simply discards some older session and re-uses its binding entry.
> Does section 2.3 of draft-srisuresh-behave-nat-icmp-01 apply, 
> since outbound packets are never rejected? By my reading, the 
> answer is NO.
> 
> 
> >> last WG meeting in Dallas:
> >>
> >> appropriate interval (every 1 minutes, 2 minutes, or whatever we 
> >> decide).
> >> for that connection was one that got re-used by the NAT for some 
> >> other purpose.
> >> connection, then the connection will stay up if the necessary 
> >> keep-alives are sent.
> >>
> >> Any comments?

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 28 Apr 2006 10:55:00 -0700 (PDT)

> yutaka_takeda@xxxxxxxxxxxxxxxxxxxx
> Sent: Friday, April 28, 2006 1:16 PM
> To: Philip Matthews
> Cc: 'Behave'
> I have the same concern as Philip does. I remember that I 
> mentioned this issue more than a year ago in this WG, but at 
> that time, my concern did not get a consensus.
> 
> I, as an application developer, still cannot answer to this question:
> 
> "How many nodes can a local UDP socket receive packets from 
> simultaneously via a NAT?"
> 
> The ICMP error does not help because an application developer 
> needs to know "how many" ahead of time. Let's say, you are 
> designing an application that runs behind a NAT and monitors 
> status of many remote nodes concurrently. How many nodes can 
> you expect to be able to monitor?

I am not sure how could a NAT tell you this information ahead of time. I
could tell you how many maximum sessions (TCP or UDP) that it could
support or allowed to support, but like you said it is not guaranteed
because there could be other applications that would be sharing the
resource space. Secondly, there could be some security concerns with
this type of support. 

Let's say there is no NAT  in the path, how many nodes would you be
willing to accept connections from? There is no one to tell you this
information ahead of time. Shouldn't that be the same number of nodes
that you are willing to support even when there is NAT?

Senthil

> 32? 256? 1024? - We really don't know. Even with '32', 
> nothing guarantees you that minimum 32 is supported by all NATs.
> 
> 
> - Yutaka
> 
> 
> 
> Philip Matthews wrote:
> > Dan:
> > 
> > I think that the section you refer to is part of the 
> answer, but not 
> > the entire answer.
> > 
> > session, then it should send an ICMP packet back to the host.
> > 
> > But consider a NAT that never rejects a new outbound session but 
> > simply discards some older session and re-uses its binding entry.
> > Does section 2.3 of draft-srisuresh-behave-nat-icmp-01 apply, since 
> > outbound packets are never rejected? By my reading, the 
> answer is NO.
> > 
> > 
> explicitly about 
> > the situation when all binding entries are in use and a 
> packet arrives 
> > that would create a new outbound session.
> > 
> > situation, as long as the proposal gives a NAT behavior that an 
> > application can work with.
> > 
> > - Philip
> > 
> > 
> > 
> >> very similar to it, satisfy your need?  The authors, chairs, and a 
> >> few others have had a long offline discussion about that ICMP 
> >> message.
> >>
> >> -d
> >>
> >>
> >>> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On 
> Behalf Of Philip 
> >>> Matthews
> >>> pick some existing binding, discard it, and then used the freed 
> >>> entry for the new packet.
> >>>
> >>> The application can always send UDP packets, but incoming UDP 
> >>> packets on that connection will get mysteriously dropped if the 
> >>> binding entry for that connection was one that got re-used by the 
> >>> NAT for some other purpose.
> >>> temporarily) whenever the applications sends the next keep-alive.
> >>>