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

From: "Senthil Sivakumar \(ssenthil\)" <[email-masked]>
Date: Mon, 4 Sep 2006 20:13:08 -0500 (CDT) (envelope-from [email-masked])

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
>

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 4 Sep 2006 20:38:07 -0500 (CDT) (envelope-from [email-masked])

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. 

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 

> 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)
> 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
> 
> > [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Brian 
> > Stucker
> assumption going 
> > forward (ie. so nobody thinks it's safe to assume the 
> latter approach 
> > is acceptable)?
> > 
> > Regards,
> > Brian
> >