Subject: [Ietf-behave] Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp)

From: The IESG <[email-masked]>
Date: Tue, 9 May 2006 07:42:35 -0700 (PDT)

The IESG has received a request from the Behavior Engineering for Hindrance 
Avoidance WG to consider the following document:

- 'NAT Behavioral Requirements for Unicast UDP '
   <draft-ietf-behave-nat-udp-06.txt> as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2006-05-23.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-06.txt

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 May 2006 03:44:09 -0700 (PDT)

Hi,

I had a flight so I read this.  I think the document gives two very 
bad pieces of advice: turn off all NAT ALGs and remove all NAT state 
mapping filtering unless you require otherwise for security reasons.

Hence, I think wider IETF review seems warranted, and I'd encourage 
more folks to read the documents and raise their concerns or lack 
thereof.

More below.

On Tue, 9 May 2006, The IESG wrote:
The IESG has received a request from the Behavior Engineering for Hindrance
Avoidance WG to consider the following document:
- 'NAT Behavioral Requirements for Unicast UDP '
  <draft-ietf-behave-nat-udp-06.txt> as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2006-05-23.
The document was very well written so it was easy to read.

As a generic comment, I'd like to know whether the different NAT mapping
methods have different scaling characteristics in terms of amount of state
created and in terms of external NAT ports/addresses reserved (compare to
the IETF list discussion a while back).
As another generic comment, I'd have liked this document to refer to RFC
4380 (Teredo), because IMHO that's probably the most useful generic
NAT traversal mechanism out there.
A few specific comments below,

substantial
-----------
   REQ-8: If application transparency is most important, it is
      RECOMMENDED that a NAT have an "Endpoint independent filtering"
      behavior.  If a more stringent filtering behavior is most
      important, it is RECOMMENDED that a NAT have an "Address dependent
      filtering" behavior.
      a) The filtering behavior MAY be an option configurable by the
         administrator of the NAT.
==> I think this is WAY too dangerous approach.  I'd say that the filtering
behaviour MUST be at least address dependent, unless explicitly configured
otherwise.
   NAT ALGs may interfere with UNSAF methods or protocols that try to be
   NAT-aware and must therefore be used with extreme caution.
   REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED
      that all of those ALGs be disabled by default.
      a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
         the NAT administrator to enable or disable each ALG separately.
==> this seems like a VERY bad advice.  You're assuming that all the protocols
used within a site (which DO work with NAT ALGs) would use UNSAF mechanisms,
i.e., it's OK for them to fail with native NAT ALGs because they can just
fall back to using UNSAF methods.
I think that UNSAF mechanisms must be able to work with ALGs enabled by
default.  If they don't, they're too brittle and should be written in a more
generic manner, with non-ALG mechanisms.
semi-editorial
--------------
      Address Dependent Mapping:
         The NAT reuses the port mapping for subsequent packets sent
         from the same internal IP address and port (X:x) to the same
         external IP address, regardless of the external port.
         Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals
         Y1.
==> this would have been easier to understand if you had added 'only' before
'reuses'.  The same for Addr/Port Dep Mapping and respective filtering
sections.
   REQ-13: If the packet received on an internal IP address has DF=1,
      the NAT SHOULD send back an ICMP message "fragmentation needed and
      DF set" message to the host as described in RFC 792 [2].
      a) If the packet has DF=0, the NAT SHOULD fragment the packet and
         send the fragments, in order.
   Justification: This is as per RFC 792.
      a) This is the same function a router performs in a similar
         situation RFC 1812 [5].
==> RFC 1812 requires that a router MUST support fragmentation, though
proper ordering of fragments is a SHOULD.  So, I'm a bit puzzled by both
of these SHOULDs.  What is the alternative?  Silently discard packets with
DF set?  Silently discard packets with DF=0 which require fragmentation? 
Maybe these should be stronger..

   Arch-3: This does not reduce the overall brittleness of NATs but will
           hopefully reduce some of the more outrageous NAT behaviors
           and make it easer to discuss and predict NAT behavior in
           given situations.
==> not sure if I agree with this statement, because you're recommending
turning off ALGs which means that some applications are going to stop
functioning.
--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Keith Moore <[email-masked]>
Date: Mon, 15 May 2006 07:12:07 -0700 (PDT)

REQ-8: If application transparency is most important, it is
      RECOMMENDED that a NAT have an "Endpoint independent filtering"
      behavior.  If a more stringent filtering behavior is most
      important, it is RECOMMENDED that a NAT have an "Address dependent
      filtering" behavior.
      a) The filtering behavior MAY be an option configurable by the
         administrator of the NAT.
==> I think this is WAY too dangerous approach.  I'd say that the filtering
behaviour MUST be at least address dependent, unless explicitly configured
otherwise.
I'd strongly disagree with that.  I'd say that NATs MUST NOT have 
address dependent filtering unless configured otherwise; and even then, 
filtering SHOULD be configurable on a (destination) port-by-port basis. 
 In other words, transparency MUST be the default setting.

   NAT ALGs may interfere with UNSAF methods or protocols that try to be
   NAT-aware and must therefore be used with extreme caution.
   REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED
      that all of those ALGs be disabled by default.
      a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
         the NAT administrator to enable or disable each ALG separately.
==> this seems like a VERY bad advice.
I agree with this.  The problem, I suspect, is that this invites 
questions about which ALGs to enable and how those ALGs should behave, 
which is a big can of worms.  Some kinds of ALGs are very bad, others 
are essential and semi-harmless.  But it certainly should not be 
expected that apps will use UNSAF methods, as UNSAF methods are woefully 
inadequate.

While I appreciate the desire to limit the problem, I think this 
document is too narrowly scoped - there's no way to define a desirable 
NAT behavior that doesn't, at a minimum, allow explicit host/application 
control over bindings in the NAT.

Keith

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 May 2006 09:23:53 -0700 (PDT)

>>>>> "Keith" == Keith Moore <moore@xxxxxxxxxx> writes:

    >> important, it is RECOMMENDED that a NAT have an "Address
    >> dependent filtering" behavior.  a) The filtering behavior MAY
    >> be an option configurable by the administrator of the NAT.  ==>
    >> I think this is WAY too dangerous approach.  I'd say that the
    >> filtering behaviour MUST be at least address dependent, unless
    >> explicitly configured otherwise.

    Keith> I'd strongly disagree with that.  I'd say that NATs MUST
    Keith> NOT have address dependent filtering unless configured
    Keith> otherwise; and even then, filtering SHOULD be configurable
    Keith> on a (destination) port-by-port basis. In other words,
    Keith> transparency MUST be the default setting.

I have not yet read the document, but believe I understand the context
for this discussion point well enough to contribute.

I think that it is important to separate NAT from firewall
functionality.  One device may provide both functions.  But if the
intent is to provide only a NAT function,, then Keith is right and
transparency needs to be the default.

If the intent is to provide a firewall function then all the
manageability and configuration concerns of a firewall apply.

---

From: Keith Moore <[email-masked]>
Date: Mon, 15 May 2006 10:31:49 -0700 (PDT)

I think that it is important to separate NAT from firewall
functionality.  One device may provide both functions.  But if the
intent is to provide only a NAT function,, then Keith is right and
transparency needs to be the default.
If the intent is to provide a firewall function then all the
manageability and configuration concerns of a firewall apply.
this ends up trying to specify how a zero-configuration firewall should 
work, or how a firewall for a dumb customer should work out-of-the-box.

it's an unreasonable problem because the network is explicitly designed 
to be general purpose and to support an infinite variety of 
applications, but the fundamental assumption behind such a firewall is 
that the firewall can be aware of what is going on in the network and 
know whether or not the network behavior it is seeing is reasonable. 
the answer to the question of whether the behavior is reasonable is 
going to vary widely from one application to another and from one 
installation to another.  there's no way that the firewall can tell by 
looking.  even expecting all conversations to be initiated from inside 
the firewall is dodgy - partially because there are legitimate apps that 
need to not work that way, partially because there are conversations 
that involve more than two hosts at a time, partially because there are 
occasions when remote hosts are forced to change IP addresses.

Keith

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 May 2006 19:29:23 -0700 (PDT)

On May 15, 2006, at 6:23 PM, Sam Hartman wrote:

The intent was never to describe how to build a firewall or a NAT. It  
was to provide a "safe harbor" of assumptions that an application  
behind a NAT or firewall could assume "behave compliant" NATs or FWs  
would provide. The BEHAVE WG has tried to find a balance between what  
had a chance of deploying and what would be enough transparency to  
allow some applications to work. Clearly more transparency would  
allow more applications to work but not if it will never be deployed.  
This particular item was discussed for a long time in the WG. The  
bulk of the running code we have today does not provide "address  
independent" mappings because of the associated security properties.  
Manufactures are building boxes that are designed for to sit in  
houses in front of windows machines run by technically  
unsophisticated users. I don't know if these boxes are NATs,  
Firewalls, or something else but no manufacture in their right mind  
is going to ship these boxes with the default as address independent  
mappings.

If we change this to "address independent", close to 100% of NATs  
produced will be non behave compliant. At this point applications  
will have nothing they can rely on and we will be at the same point  
we are now and the BEHAVE WG will have been reduce to an irrelevant  
waste of time.

I 100% agree that if we were advising people how to build NATs, we  
would recommend "address independent", however this is not the  
situation.

Cullen (with my individual contributor hat on)

---

From: Keith Moore <[email-masked]>
Date: Thu, 18 May 2006 19:44:21 -0700 (PDT)

If we change this to "address independent", close to 100% of NATs 
produced will be non behave compliant. At this point applications will 
have nothing they can rely on and we will be at the same point we are 
now and the BEHAVE WG will have been reduce to an irrelevant waste of time.
what's the point of this exercise?  to encourage predictable behavior 
that applications cannot use?  to give NAT vendors a seal of approval?

maybe it's just not possible to specify a NAT such that it's useful to 
application writers and vendors will build it...at least, not without 
significant functionality beyond just address translation and packet 
filtering.

Keith

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 May 2006 15:20:13 -0700 (PDT)

On May 18, 2006, at 7:44 PM, Keith Moore wrote:

If we change this to "address independent", close to 100% of NATs  
produced will be non behave compliant. At this point applications  
will have nothing they can rely on and we will be at the same  
point we are now and the BEHAVE WG will have been reduce to an  
irrelevant waste of time.
what's the point of this exercise?
To try and minimize the damage NATs cause - clearly if NATs all acted  
like a peice of cat 5 cable, that would be optimial from some points  
of view but this is not likely to happen. So it was a balance to  
define something that was extremely useful for applications (more on  
that later) and yet close enough to what NATs do that some, and  
hopefully most, NAT vendors will do it.

to encourage predictable behavior that applications cannot use?
The functionaly here defined here allow two hosts behind two differnt  
NATs to be able to set up a dirrect flow of packets between them.  
They need an external STUN server in the public space to help them  
with this but they don't need to realy all the packets through a  
server. The two hosts use some server that is not NATed to help set  
up the connection, but once the connection is up, there is real e2e  
flow of packets and the packets don't have to be relayed by some  
public server. Clearly this is not as nice for applications as no  
NAT, but short of no NAT, this is really useful and helps provide the  
scaleabilyt and reliabilyt that would be achievable in a system with  
no NATs. VoIP, IM, and online games can all take advantage of this -  
and using ICE they can do it in a way that provides a smoth  
transition to v6 or envirnoments with no NATs. I think the behavior  
defined here is useful for applications.

---

From: Keith Moore <[email-masked]>
Date: Mon, 22 May 2006 15:41:06 -0700 (PDT)

> To try and minimize the damage NATs cause 

Well, as far as I can tell, you're not doing that to any significant
degree. 

> NATs to be able to set up a dirrect flow of packets between them. 

A solution that only works for pairs of hosts is of fairly limited
applicability. Most two-host applications already work through NAT.
The biggest set of apps affected by NAT are distributed applications.

Again, maybe it's not possible to define a spec that NAT vendors will
implement that gets rid of NAT brain damage to any useful degree.  If
this is the belief of the BEHAVE WG then  the correct output of the
BEHAVE group is to state that belief, rather than to define a spec that
provides the appearance of a solution while only providing a very
marginal increase in actual functionality. 

Personally I'm tired of attempts to avoid solving the NAT problem while
glossing over it.  I don't think IETF should be endorsing NAT fixes
that don't provide a path to a viable long-term solution.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 23 May 2006 12:25:02 -0700 (PDT)

Hi Pekka,

Not sure if your questions about ALG ever got answered so wanted to  
restart that thread.  More inline ....

On May 15, 2006, at 3:44 AM, Pekka Savola wrote:
   NAT ALGs may interfere with UNSAF methods or protocols that try  
to be
   NAT-aware and must therefore be used with extreme caution.

   REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED
      that all of those ALGs be disabled by default.
      a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
         the NAT administrator to enable or disable each ALG  
separately.

==> this seems like a VERY bad advice.  You're assuming that all  
the protocols
used within a site (which DO work with NAT ALGs) would use UNSAF  
mechanisms,
i.e., it's OK for them to fail with native NAT ALGs because they  
can just
fall back to using UNSAF methods.
I think the important thing to keep in mind here is this is only  
scoped to UDP. We are not saying this about TCP ALGs.  The WG did  
talk about this for a long time. There are devices with UDP ALG that  
everyone agrees are bad (more on this later) - the questions is are  
there any that we would recommend?  The only one that ever came up as  
DNS and most people did not think this was even really a ALG as the  
NAT provided (via DHCP) it's address and the request was sent there.  
I don't recall other UDP based ALGs being brought up.

I think that UNSAF mechanisms must be able to work with ALGs  
enabled by
default.  If they don't, they're too brittle and should be written  
in a more
generic manner, with non-ALG mechanisms.

I have two NATs on my shelf right now that have an interesting ALG in  
them. If the NAT has a public address of 1.1.1.1 any time it see the  
string "1.1.1.1" or the 32 bit value 0x01010101 in any packet, it  
replaces it with the private address. Say you are FTP a file that  
happens to have the bit sequences, well it gets replaces. I don't  
think we should design applications to work with this ALG - I think  
we should encourage people not to deploy something so broken.

I also have some NATs with SIP ALGs. I will talk about the one from  
the vendor I work for but as far as I can tell other vendors are no  
better. The SIP ALG regularly tampers with things in a way that  
breaks things in very unpredictable ways. It will rewrite some  
address but not others - it is very difficult for any UNSAF algorithm  
to know what parts of the message might get tampered with and to stop  
that. For example, if you are doing ICE and want to pass your local  
and public address  the ALG tends to rewrite the private address with  
the public address and some times leaves the public address along and  
sometimes tries to change it if it matches a flow it recognizes.

If we had an RFC that described an specific UDP ALG and said how it  
worked, I would be all for saying leave that on. However, what we are  
trying to do is make the NATs somewhat deterministic from point of  
view of applications using them. We can not meet that goal and have  
random ALG on the NAT that may make complete unknown transformations  
to any packet.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 May 2006 04:38:43 -0700 (PDT)

On Tue, 23 May 2006, Cullen Jennings wrote:
I think that UNSAF mechanisms must be able to work with ALGs enabled by
default.  If they don't, they're too brittle and should be written in a 
more
generic manner, with non-ALG mechanisms.

I have two NATs on my shelf right now that have an interesting ALG in them. 
If the NAT has a public address of 1.1.1.1 any time it see the string 
"1.1.1.1" or the 32 bit value 0x01010101 in any packet, it replaces it with 
the private address. Say you are FTP a file that happens to have the bit 
sequences, well it gets replaces. I don't think we should design applications 
to work with this ALG - I think we should encourage people not to deploy 
something so broken.
That kind of NAT box is very broken -- and has very little as such to 
do with ALG, which are (in my book) application-specific.

I also have some NATs with SIP ALGs. I will talk about the one from the 
vendor I work for but as far as I can tell other vendors are no better. The 
SIP ALG regularly tampers with things in a way that breaks things in very 
unpredictable ways. It will rewrite some address but not others - it is very 
difficult for any UNSAF algorithm to know what parts of the message might get 
tampered with and to stop that.
I don't agree with this line of reasoning.  I'd pose the question as 
follows:

  Which is worse, application not working AT ALL (because there is no
  ALG, nor NAT traversal mechanism) or that application works with
  correctly implemented ALGs (or works "most of the time" implying
  with typical usage patterns but more advanced ones might not work)?
You seem to be assuming that all the applications for which there is 
an ALG have their own NAT traversal mechanism, so disabling the ALG is 
OK as the application can work using the NAT-traversal method.  While 
this may or may not be the case for SIP, I do not think this is the 
case in general -- and you're recommending disabling UDP ALGs in 
general.

For example, if you are doing ICE and want to pass your local and 
public address the ALG tends to rewrite the private address with the 
public address and some times leaves the public address along and 
sometimes tries to change it if it matches a flow it recognizes.
We may have a terminology conflict here.

First of all, I'm all for strongly disallowing NAT features which 
blindly replace strings with other strings, or 32 bit binary blobs 
with other binary blobs.

In my book, "ALG" refers to a mechanism that is specific to an 
application: identified by application identifier strings, the type 
and content of messaging, or even just a well-known port number.

It seems you're saying that a NAT traversal mechanism like ICE is 
embedded in an application (SIP?) for which there exists an ALG, so 
that ALG has the possibility of breaking ICE.

Maybe in that case you should just recommend that SIP ALG is disabled, 
or that it must be implemented in such a manner that it doesn't 
interfere with ICE (or maybe ICE design needs to be changed so it 
doesn't get mixed in an ALG).

Further, I'd say that if we want a generic NAT traversal mechanism to 
be successful (instead of reinventing it for every single 
application), it MUST be separate from any application, and therefore 
unhampered by application-specific ALGs.  Therefore I do not see the 
problem with ALGs in general.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 25 May 2006 14:16:13 -0700 (PDT)

As Pekka suggests, he and I may just be using the wrong words but  
agree about the fundamentals of this. I put some comments inline then  
a possible suggestion to resolve this at the bottom.

On May 25, 2006, at 4:38 AM, Pekka Savola wrote:

	autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  
otso.netcore.fi

On Tue, 23 May 2006, Cullen Jennings wrote:
I think that UNSAF mechanisms must be able to work with ALGs  
enabled by
default.  If they don't, they're too brittle and should be  
written in a more
generic manner, with non-ALG mechanisms.
I have two NATs on my shelf right now that have an interesting ALG  
in them. If the NAT has a public address of 1.1.1.1 any time it  
see the string "1.1.1.1" or the 32 bit value 0x01010101 in any  
packet, it replaces it with the private address. Say you are FTP a  
file that happens to have the bit sequences, well it gets  
replaces. I don't think we should design applications to work with  
this ALG - I think we should encourage people not to deploy  
something so broken.
That kind of NAT box is very broken -- and has very little as such  
to do with ALG, which are (in my book) application-specific.
ok - we might be close to same page then

I also have some NATs with SIP ALGs. I will talk about the one  
from the vendor I work for but as far as I can tell other vendors  
are no better. The SIP ALG regularly tampers with things in a way  
that breaks things in very unpredictable ways. It will rewrite  
some address but not others - it is very difficult for any UNSAF  
algorithm to know what parts of the message might get tampered  
with and to stop that.
I don't agree with this line of reasoning.  I'd pose the question  
as follows:

  Which is worse, application not working AT ALL (because there is no
  ALG, nor NAT traversal mechanism) or that application works with
  correctly implemented ALGs (or works "most of the time" implying
  with typical usage patterns but more advanced ones might not work)?
I will explain some experience of running code but I suspect you and  
I both agree on works some of the time is better than never works.

The number one NAT vendor (by number of NATs shipped) turned on a SIP  
ALG one day. This ALG had no real way of knowing if a message was a  
SIP message or just something that looked like SIP. It looked at the  
destination port being 5060. If you happen to be running RTSP or HTTP  
server on 5060, it went and applied the SIP ALG. The SIP ALG  
conceited of arbitrarily searching for strings in right places and  
replacing them - it's hard to specify any ALG that does not do this.  
Although the ALG had good intentions, if you send an IM that  
contained you IP address, well it got changes in the text of the IM.  
No one thought this was great and clearly a smarter ALG could have  
avoided this. However, no ALG could have been smart enough such that  
a backward compatible extension to the SIP protocol would not result  
in some situation where the ALG did the wrong thing. The reason there  
is not an RFC for a SIP ALG is because it is impossible to write a  
SIP ALG that works and will work in the future.

Now you might thing this ALG at least did not make things any worse -  
well that is where the problems started. It made things way worse. At  
the point in time this was releases, many existing soft-phone and IM  
clients works just fine behind NATs. However, this ALG broke them all  
- it arbitrarily trashed bits in the message and the device could not  
figure out which bits it trashed and which ones it did not. This made  
for avery non deterministic experience - There was many howls of  
complaints from customers and the vendor went and turned off the ALG.

Now I know there are more protocols on the internet than just  
SIP :-), but many other are similar in that there is no defined way  
to ALG them that does not break the protocol.

You seem to be assuming that all the applications for which there  
is an ALG have their own NAT traversal mechanism, so disabling the  
ALG is OK as the application can work using the NAT-traversal  
method.  While this may or may not be the case for SIP, I do not  
think this is the case in general -- and you're recommending  
disabling UDP ALGs in general.
Let me turn the question around - which ALGs to you recommend we turn  
on? If there are ones that don't cause serious harm and are well  
specified, I imagine people would be glad to turn them on.

For example, if you are doing ICE and want to pass your local and  
public address the ALG tends to rewrite the private address with  
the public address and some times leaves the public address along  
and sometimes tries to change it if it matches a flow it recognizes.
We may have a terminology conflict here.

First of all, I'm all for strongly disallowing NAT features which  
blindly replace strings with other strings, or 32 bit binary blobs  
with other binary blobs.
In this case, I think you and I will come to the same end conclusion  
on this one.

In my book, "ALG" refers to a mechanism that is specific to an  
application: identified by application identifier strings, the type  
and content of messaging, or even just a well-known port number.
Ok - I think that we would agree that something like a HTTP Cache  
which is well specified, and designed for when updating the HTTP  
protocol, would be fine to turn on. I realize this is not exactly an  
ALG but if we had an ALG with the properties of web cache as far as  
deterministic behavior goes, I would have no problem with it.

Maybe in that case you should just recommend that SIP ALG is  
disabled, or that it must be implemented in such a manner that it  
doesn't interfere with ICE (or maybe ICE design needs to be changed  
so it doesn't get mixed in an ALG).

Further, I'd say that if we want a generic NAT traversal mechanism  
to be successful (instead of reinventing it for every single  
application), it MUST be separate from any application, and  
therefore unhampered by application-specific ALGs.  Therefore I do  
not see the problem with ALGs in general
Here is my suggestion. We say something like

All UDP ALGs other than X,Y,Z be turned off. Any future standards  
track documents that define an ALG MAY update this draft to recommend  
that the ALG for that protocol be turned on by default.

I'm happy to put any protocol in the X,Y,Z list as long as it has a  
well defined ALG that will not break applications.

Cullen <with my individual contributor hat on>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 25 May 2006 14:38:32 -0700 (PDT)

I'm reading what Pekka is saying as very different from what you and I
are saying.

Pekka, can you propose a wording that will be acceptable to us?

As Cullen suggest, if you have particular ALGs that you have in mind,
let us know. But we couldn't figure out any UDP ALG that should be on
by default.

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] 
> Sent: Thursday, May 25, 2006 14:16
> To: Pekka Savola
> Cc: Behave WG; Audet, Francois [SC100:3055:EXCH]; Magnus Westerlund
> Subject: Re: [Ietf-behave] Re: Last Call: 'NAT Behavioral 
> Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp) 
> 
> 
>