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

From: Cullen Jennings <[email-masked]>
Date: Wed, 6 Sep 2006 11:27:41 -0500 (CDT) (envelope-from [email-masked])

We tried on some of this long ago and it was a complete failure to  
get people to agree on anything remotely resembling minimum  
performance criteria for NATs. Everyone agreed it would be nice if we  
could agree on something but every time someone put a number on the  
table people had many reasons why that number could not possibly work  
for them.

On Sep 5, 2006, at 11:07 PM, David Barrett wrote:

I concur.  Option C seems best.

-----Original Message-----
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))
Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Ietf-behave] Time to add mapping/filtering entries

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

-----Original Message-----
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
Subject: Re: [Ietf-behave] Time to add mapping/filtering entries

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)
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: Wed, 6 Sep 2006 14:47:00 -0500 (CDT) (envelope-from [email-masked])

I agree with you there.  I'm merely suggestion we recommend NAT's be
configured by default to not explicitly filter NAT mappings based on
criteria other than resource constraints.  

Whether your device supports 1 or 1M NAT bindings per second doesn't matter.
Rather, we recommend that number should be as high as you can conceivably
make it by default, with rate-limited NAT binding being an optional
(non-default) feature.

-david

> Sent: Wednesday, September 06, 2006 9:27 AM
> To: David Barrett
> Cc: 'Brian Stucker'; 'Senthil Sivakumar ((ssenthil))'; ietf-
> behave@xxxxxxxxxxxxxxxxxxx