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

From: "Eric Cooper" <[email-masked]>
Date: Wed, 16 Aug 2006 14:25:45 -0500 (CDT) (envelope-from [email-masked])

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.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 22 Aug 2006 19:12:03 -0500 (CDT) (envelope-from [email-masked])

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.

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

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 22 Aug 2006 21:20:21 -0500 (CDT) (envelope-from [email-masked])

It would seem that the NATs are relying on the retransmission regiments
of others to handle their overload issues. I wonder if this dropping of
packets is also considered to be protection against a DoS attacks?

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
> 
> 
> 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.
> 
> 
> 
> 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.
> >

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 28 Aug 2006 11:56:03 -0500 (CDT) (envelope-from [email-masked])

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 4 Sep 2006 19:28:41 -0500 (CDT) (envelope-from [email-masked])

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,

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

Regards,
Brian

-----Original Message-----

Hi All,

Establishment'

5-25 per ICE

packets such

filtering

experiment with

Thanks!

Eric Cooper.

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 4 Sep 2006 20:03:41 -0500 (CDT) (envelope-from [email-masked])

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

---

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

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 

> From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] 
> Sent: Monday, September 04, 2006 8:04 PM
> To: Cullen Jennings; Stucker, Brian (RICH1:B620)
> 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
> 
> > > 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
> > >
> > >> 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.
> > >>
> > >> with HTTP traffic -- and have it work well all the time. All my 
> > >> testing has been with UDP not TCP.
> > >>
> > >>> Ethereal and my browser seems to indicate that HTTP GET 
> requests 
> > >>> to different servers are not spaced 50 ms apart.
> > >>>
> > >>> 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.
> > >>>