Subject: Re: [Ietf-behave] Time to add mapping/filtering entries

From: "Kaushik Biswas \(kbiswas\)" <[email-masked]>
Date: Tue, 5 Sep 2006 15:48:38 -0500 (CDT) (envelope-from [email-masked])

> I think we could make a generic requirement statement that 
> "NATs should not do any rate limiting unless explicitly 
> configured to do so." 

This might be difficult for vendors to adhere to, since rate limiting
might get done not only for virus-protection (which are mostly config
driven like per-host rate-limiting,etc) but also might happen due to
each vendor's internal memory-management schemes amongst others. If
someone is pounding you with STUN packets every 5ms for 6 minutes, that
might be okay on a particular vendor (say vendor A) as that's how their
memory-management scheme might be, but might not be ok with another
vendor (say vendor B). And actually vendor A might be quoting that in
their performance-results and telling why they are better over vendor B.
Now one shouldn't be putting in some statement which makes vendor B not
complaint just because its CPU/memory-management scheme may not be fast
enough. IMO, it is good to highlight this issue, as was found in
Cullen's tests that certain NATs can handle traffic-rate better than
others, but we should stop short of a recommendation in this regard.

Thanks,
Kaushik

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Senthil Sivakumar (ssenthil)
> Sent: Tuesday, September 05, 2006 6:56 AM
> To: Brian Stucker; Pyda Srisuresh; Cullen Jennings (fluffy)
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Ietf-behave] Time to add mapping/filtering entries
> 
>  
> 
> > -----Original Message-----
> > From: Brian Stucker [mailto:bstucker@xxxxxxxxxx]
> > Sent: Monday, September 04, 2006 9:38 PM
> > To: Senthil Sivakumar (ssenthil); Pyda Srisuresh; Cullen Jennings 
> > (fluffy)
> > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Ietf-behave] Time to add mapping/filtering entries
> > 
> > The recommendation does not imply a binary decision, just 
> that it has 
> > impacts on the behavior of protocols designed explicitly to help 
> > manage NAT interactions (ie. STUN) over short periods of time.
> > 
> > I'm assuming a happy medium can be reached as has been brokered on 
> > other NAT related behaviors.
> > 
> > If someone's pounding you with STUN packets every 5ms for 6 
> minutes, 
> > their packets deserve to be sent to /dev/null. If someone 
> happens to 
> > hit you with 3 o 4 STUN packets every 20ms for 100ms, 
> that's probably 
> > not an attack.
> > 
> > My point, is that volumetric controls on rate limiting 
> absent context 
> > are going to run the risk of breaking benign applications. 
> Unless some 
> > parameters on what's acceptible are agreed upon it will be 
> impossible 
> > to verify that the protocol works beyond ancedotal evidence.
> 
> It is true that volumetric controls can be bad, but it is 
> upto the admin to determine what is the acceptable level in 
> his/her network. Also, different applications have different 
> characteristics and a NAT controlling it by some hard coded 
> means isn't a great solution. However, if this is a 
> configurable option for the admin to specify the rules for 
> rate limiting, then it provides enough tools and controls for 
> the admin.
> I think we could make a generic requirement statement that 
> "NATs should not do any rate limiting unless explicitly 
> configured to do so." 
> 
> Thanks
> Senthil
> 
> > 
> > The only way I see to improve upon this would be to documenting the 
> > assumptions that are made about the behavior of a given NAT with 
> > respect to dropping messages, and to put that 
> > assumption/recommendation somewhere that a NAT designer will see it 
> > that couldn't give a hoot about STUN.
> > 
> > Regards,
> > Brian
> > 
> > > -----Original Message-----
> > > From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@xxxxxxxxx]
> > > Sent: Monday, September 04, 2006 8:13 PM
> > > To: Stucker, Brian (RICH1:B620); Pyda Srisuresh; Cullen Jennings
> > > (fluffy)
> > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> > > Subject: RE: [Ietf-behave] Time to add mapping/filtering entries
> > > 
> > > Do you mean it is not acceptable to have per-source rate
> > limiting? If
> > > so, why? Cisco IOS NAT supports various types of rate-limiting 
> > > including per-source. One of the main reasons to have to support 
> > > per-source rate limiting was because of virus affected 
> end stations 
> > > that could potentially fill up the NAT table and eventually
> > causing it
> > > to crash..
> > > 
> > > Senthil
> > > 
> > > > -----Original Message-----
> > > > From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> > > > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On
> > Behalf Of Brian
> > > > Stucker
> > > > Sent: Monday, September 04, 2006 9:06 PM
> > > > To: Pyda Srisuresh; Cullen Jennings (fluffy)
> > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> > > > Subject: Re: [Ietf-behave] Time to add mapping/filtering entries
> > > > 
> > > > Can a recommendation be made somewhere to codify that
> > > assumption going
> > > > forward (ie. so nobody thinks it's safe to assume the
> > > latter approach
> > > > is acceptable)?
> > > > 
> > > > Regards,
> > > > Brian
> > > > 
> > > > > -----Original Message-----
> > > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx]
> > > > > Sent: Monday, September 04, 2006 8:04 PM
> > > > > To: Cullen Jennings; Stucker, Brian (RICH1:B620)
> > > > > Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> > > > > Subject: Re: [Ietf-behave] Time to add 
> mapping/filtering entries
> > > > > 
> > > > > I agree with Cullen's comment below. Binding entry 
> creation is 
> > > > > resource constrained at a global level, not ona
> > per-source basis,
> > > > > AFAIK.
> > > > > 
> > > > > cheers,
> > > > > suresh
> > > > > 
> > > > > --- Cullen Jennings <fluffy@xxxxxxxxx> wrote:
> > > > > 
> > > > > > 
> > > > > > I looked at some code for a residential NAT and an high end 
> > > > > > enterprise. I strongly suspect that there was no per
> > > > source address
> > > > > > rate limiting code but instead just limits on when the
> > > > CPU got too
> > > > > > busy in general. I may have gotten this all wrong, staring
> > > > > at a bunch
> > > > > > of NAT code that you did not write is a mind 
> numbing process.
> > > > > > 
> > > > > > 
> > > > > > On Aug 28, 2006, at 9:55 AM, Brian Stucker wrote:
> > > > > > 
> > > > > > > Random thought,
> > > > > > >
> > > > > > > Does anyone know if the speed of NATs creating new
> > > > bindings being
> > > > > > > limited due to dropping occurs in aggregate, or is it
> > > > > limited only
> > > > > > > to requests coming in from a single source address?
> > > > > > >
> > > > > > > If it's a problem in aggregate (meaning it'll drop new
> > > > > bindings if
> > > > > > > the overall rate is too high) that might not bode well
> > > > for large
> > > > > > > numbers of clients using STUN for connectivity checks
> > > > behind some
> > > > > > > NATs.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Brian
> > > > > > >
> > > > > > >> -----Original Message-----
> > > > > > >> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
> > > > > > >> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On
> > > Behalf Of
> > > > > > >> Cullen Jennings
> > > > > > >> Sent: Tuesday, August 22, 2006 7:12 PM
> > > > > > >> To: Eric Cooper
> > > > > > >> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> > > > > > >> Subject: Re: [Ietf-behave] Time to add
> > > > mapping/filtering entries
> > > > > > >>
> > > > > > >>
> > > > > > >> My test program that classifies NATs runs a bunch of
> > > tests in
> > > > > > >> parallel.  If you run the stun packets with no gap, it
> > > > is clear
> > > > > > >> that many NATs just lose some of the state they should
> > > > > be storing
> > > > > > >> even though they forwarded the packet.  When I gap by 10
> > > > > ms, most
> > > > > > >> NATs seem to work and I don't think I have anything that
> > > > > fails if I
> > > > > > >> am at 20 ms but it is hard to test.
> > > > > > >> There are reports that my test program fails on some
> > > > > NATs with 50ms
> > > > > > >> gaps but I have not been able to replicate this.
> > > > > > >>
> > > > > > >> I have not investigated if you can burst a small number
> > > > > -- such as
> > > > > > >> with HTTP traffic -- and have it work well all the
> > > > time. All my
> > > > > > >> testing has been with UDP not TCP.
> > > > > > >>
> > > > > > >> If people want to play with this, the software is the
> > > > > open source
> > > > > > >> stuff at vovida.org.
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> On Aug 16, 2006, at 12:25 PM, Eric Cooper wrote:
> > > > > > >>
> > > > > > >>> Hi All,
> > > > > > >>>
> > > > > > >>> I've recently been looking into 'Internet Connectivity
> > > > > > >> Establishment'
> > > > > > >>> (ICE), which contains some statements indicating that
> > > > > some NAT/FW
> > > > > > >>> devices may be overwhelmed if they need to create a
> > > > > bunch of new
> > > > > > >>> mapping and/or filtering entries in a short
> > amount of time.
> > > > > > >>>
> > > > > > >>> Specific to ICE, 'a bunch' is somewhere on the order of
> > > > > > >> 5-25 per ICE
> > > > > > >>> endpoint.  ICE indicates that endpoints should 
> rate limit
> > > > > > >> packets such
> > > > > > >>> that packets which would likely create new 
> mapping and/ or
> > > > > > >> filtering
> > > > > > >>> entries are spaced 50 ms apart.
> > > > > > >>>
> > > > > > >>> I wonder if this spacing is really necessary.  A quick
> > > > > > >> experiment with
> > > > > > >>> Ethereal and my browser seems to indicate that HTTP GET
> > > > > requests
> > > > > > >>> to different servers are not spaced 50 ms apart.
> > > > > > >>>
> > > > > > >>> My questions to the group are:
> > > > > > >>>
> > > > > > >>> 1) Does anyone have any empirical data regarding
> > > the speed at
> > > > > > >>> which new mapping/filtering entries can be created on
> > > > > various devices?
> > > > > > >>>
> > > > > > >>> 2) What is your opinion w.r.t. this 50 ms 
> spacing?  Is it 
> > > > > > >>> necessary for existing devices, and will it
> > continue to be
> > > > > > >>> necessary for BEHAVE-NAT-UDP compliant devices?
> > > > > > >>>
> > > > > > >>> Thanks!
> > > > > > >>>
> > > > > > >>> Eric Cooper.
> > > > > > >>>
> > > > > > >>> _______________________________________________
> > > > > > >>> 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
> > > > > > >>
> > > > > > _______________________________________________
> > > > > > 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
> > > > 
> > > 
> > 
> 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: "David Barrett" <[email-masked]>
Date: Tue, 5 Sep 2006 17:18:30 -0500 (CDT) (envelope-from [email-masked])

> From: Kaushik Biswas (kbiswas)
> 
> ...

(Been silent for a bit but speaking up as I'm working with precisely this
issue right now)

I agree we shouldn't make a device non-compliant due to having insufficient
resources to handle a particular volume of NAT bindings (CPU, memory, etc).
But I agree with Senthil that we should recommend against NATs rate-limiting
new bindings that they could otherwise handle, unless explicitly configured
to do so.

(Incidentally, I'd count virus software and other automated reconfigurations
as "explicitly configured" for the sake of this argument.)

-david