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

From: "Senthil Sivakumar \(ssenthil\)" <[email-masked]>
Date: Tue, 5 Sep 2006 08:56:23 -0500 (CDT) (envelope-from [email-masked])

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

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 5 Sep 2006 18:32:52 -0500 (CDT) (envelope-from [email-masked])

What folks are saying on this thread makes sense to me. I think that  
rate limiting is definitely falling into the firewall behavior type  
space. We tried to keep this out of scope for behave because it is  
such a large set of problems to try and tackle.

On Sep 5, 2006, at 6:56 AM, Senthil Sivakumar ((ssenthil)) wrote:

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

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

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)

limiting? If

causing it

to crash..

Senthil

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

Behalf Of Brian

Stucker

assumption going

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

per-source basis,

AFAIK.

cheers,
suresh

source address

CPU got too

at a bunch

Random thought,

bindings being

limited only

bindings if

for large

behind some

NATs.

Regards,
Brian

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

Behalf Of

Cullen Jennings

tests in

is clear

be storing

ms, most

fails if I

NATs with 50ms

-- such as

time. All my

open source

stuff at vovida.org.

Hi All,

Establishment'

some NAT/FW

bunch of new

amount of time.

5-25 per ICE

packets such

filtering

experiment with

requests

the speed at

various devices?

continue to be

Thanks!

Eric Cooper.

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 6 Sep 2006 00:44:19 -0500 (CDT) (envelope-from [email-masked])

So,

In relation to rate limiting behavior of a NAT, do we need to say:

A. Nothing.
B. Mention possible problems, but give no recommendations to NAT
desigers/administrators about what to do about it.
C. Mention possible problems, and give recommended guidelines for
dealing with it (simple formulas or minimal expected behavior).

To me, A is not a real option because this thread has generated enough
interest that it's obviously worth debating, so it's probably worth
mentioning (also, nobody has claimed that a potential problem does not
exist).

It's been argued below that it can be left up to configuration which may
be true in many contexts. However, configuration variables need a
default value. STUN should work with any out-of-the-box NAT that is
BEHAVE compliant. This means that although configuration could be used
it should not be required to make STUN work.

Finally, not all NATs are designed to allow administrators the
opportunity to tweak every possible variable into the NAT's behavior.
Therefore, configuration may not be possible (and we still want a
reasonable degree of certainty that STUN will work properly if the NAT
is BEHAVE compliant).

So, in the interest of leaving the guesswork out of the process, but not
tying the hands of the administrator, I'd vote for C.

Regards,
Brian

> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] 
> Sent: Tuesday, September 05, 2006 6:33 PM
> To: Senthil Sivakumar ((ssenthil))
> Cc: Stucker, Brian (RICH1:B620); Pyda Srisuresh; 
> ietf-behave@xxxxxxxxxxxxxxxxxxx
> What folks are saying on this thread makes sense to me. I 
> think that rate limiting is definitely falling into the 
> firewall behavior type space. We tried to keep this out of 
> scope for behave because it is such a large set of problems 
> to try and tackle.
> 
> 
> >> To: Senthil Sivakumar (ssenthil); Pyda Srisuresh; Cullen Jennings 
> >> (fluffy)
> 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.
> >
> > admin to determine what is the acceptable level in his/her network. 
> > Also, different applications have different characteristics 
> and a NAT 
> > 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
> >
> >>

---

From: "David Barrett" <[email-masked]>
Date: Wed, 6 Sep 2006 01:07:16 -0500 (CDT) (envelope-from [email-masked])

I concur.  Option C seems best.

> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx [mailto:ietf-behave-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Brian Stucker
> Sent: Tuesday, September 05, 2006 10:44 PM
> To: Cullen Jennings; Senthil Sivakumar ((ssenthil))