Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 May 2005 11:33:22 -0700 (PDT)

Correct.

> -----Original Message-----
> From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx 
> [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] 
> Sent: Thursday, May 26, 2005 11:18
> To: Cullen Jennings
> Cc: Audet, Francois [SC100:9T51:EXCH]; 'Bryan Ford'; Behave
> Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7
> 
> 
> I am ok with this, too..
> assuming that Fancois meant:
> 
> REQ-7:
>    A NAT SHOULD support Endpoint Independent Filtering
>    or Address Dependent Filtering.
> 
> Observing the arguments, it is convincing me that the 
> arguments on the default filtering behavior is not a behave's 
> primary goal, nothing more than just an option for router 
> developers to choose. (as well as other firewall options 
> which are out of scope of behave, which how I view)
> 
> REQ-1, 3, 5, 6, 8 already cover the most important aspects of 
> NAT behavior for us to design applications in a deterministic manner.
> 
> REQ-7 justification looks very good to me. Especially, that 
> Endpoint-specific filtering is not a recommendation and 
> mentioning in the justification the benefit of the 
> recommendation in REQ-7 with using 
> ICE is very important for us to reduce requirement to a media 
> relay, particularly in the transition to full deployment of 
> behave compliant NATs.
> 
> - Yutaka
> 
> 
> Cullen Jennings wrote:
> > 
> > I'm in agreement with that. (and fix my typo s/should/SHOULD/ )
> > 
> > On 5/25/05 11:25 AM, "Francois Audet" <audet@xxxxxxxxxx> wrote:
> > 
> >     Man, this is difficult....
> > 
> >     We have the following proposals on the table:
> > 
> >     REQ-7: Favored by Bryan, Sriruresh, Yutaka
> > 
> >             NATs SHOULD support Endpoint Independent 
> Filtering and Address
> >             Dependent Filtering, and MAY support Address 
> and Port Dependent
> >             Filtering, as options configurable by the user. It is
> >     RECOMMENDED
> >             that Endpoint Independent Filtering be the default.
> > 
> >       Cullen strongly opposes the last sentence, and the 
> configuration
> >       option.
> > 
> > 
> > 
> >     REQ-7: Favored by Cullen (as co-author, not chair), and maybe 
> > others
> > 
> >             A NAT should support Endpoint Independent Filtering
> >             or Address and Port Dependent Filtering.
> > 
> > 
> >     I am not sure if Bryan strongly opposes Cullen's 
> proposal, or if he
> >     mildly opposes it.
> > 
> >     I'm not sure either what are Christian and Jon's 
> preferences at this
> >     point.
> > 
> >     Personally, I don't really care as I believe the justification
> >     (below) is more important since there is no MUST. I do 
> have a mild
> >     preference for Cullen's.
> > 
> >     REQ-7 justification:
> > 
> >             The recommendation to use Endpoint Independent 
> Filtering is
> >     aimed at maximizing
> >             application transparency, in particular for applications
> >     that receive media
> >             simultaneously from multiple locations (e.g., 
> gaming), or
> >     applications that use
> >             rendezvous techniques. However, it is also 
> possible that in
> >     some circumstances, it
> >             may be preferable to have a more stringent filtering
> >     behavior. Filtering
> >             independently of the external endpoint is not 
> as secure: an
> >     unauthorized packet
> >             could get a specific port while the port was 
> kept open if it
> >     was lucky enough to
> >             find the port open. In theory, filtering based 
> on both IP
> >     address and port is more
> >             secure than filtering based only on the IP 
> address (because
> >     the external endpoint
> >             could in reality be two endpoints behind 
> another NAT, where
> >     one of the two
> >             endpoints is an attacker): however, such a policy could
> >     interfere with
> >             applications that expect to receive UDP packets 
> on more than
> >     one UDP port.
> >             Using Endpoint Independent Filtering or Address 
> Dependent
> >     Filetering instead of
> >             Address and Port Dependent Filtering on a NAT 
> (say NAT-A)
> >     also has benefits
> >             when the other enpoint is behind a non-BEHAVE 
> compliant NAT
> >     (say NAT-B) which
> >             doesn't support REQ-1. When the endpoints use 
> ICE, if NAT-A
> >     uses Address and Port
> >             Dependent Filtering, connectivity will require a Media
> >     Relay. However, if NAT-A
> >             uses Endpoint Indepent Filtering or Address Dependent
> >     Filtering, ICE will
> >             ultimately find connectivity without requiring a Media 
> > Relay.
> > 
> > 
> >     I believe we have a rough concensus on the 
> justification text above.
> >     It makes it
> >     clear why you would choose one or the other.
> > 
> >     My proposal:
> > 
> >     - Adopt Cullen's text. However, include in the 
> justification, the
> >     following text:
> > 
> >             A NAT vendor could could satisfy the maximum application
> >     transparency
> >             requirement versus the maximum security requirement by
> >     having a configuration
> >             option allowing choosing between, respectively, Endpoint
> >     Independent Filtering
> >             and Address Dependent Filtering.
> > 
> >     If this proposal fails, then I'm not sure what to do. 
> Seems to me
> >     we've beaten this
> >     to death and we might need a Chair or AD make a decision...
> > 
> > 
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > _______________________________________________
> > Ietf-behave mailing list
> > Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 21 Jun 2005 17:04:20 -0700 (PDT)

My understanding too.

Let's wait for Cullen to clarify.

> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Saikat Guha
> Sent: Tuesday, June 21, 2005 15:07
> To: Bryan Ford
> Cc: 'Behave'
> On Tue, 2005-06-21 at 21:21 +0200, Bryan Ford wrote:
> > In what way do they still hold?
> 
> I think you misunderstood what Cullen was objecting to. 
> 
> > > On Wed, 2005-06-01 at 09:25 -0400, Cullen Jennings wrote:
> > > > I could deal with this if we change to MAY but strongly 
> object to 
> > > > the SHOULD. There are going to be devices where this is 
> difficult. 
> > > > There are going to be devices that only support one type.
> 
> Yep. If the NAT supports only one type (EF=I or EF=A), it 
> would be difficult to have the config option regardless of 
> whether it is the end- user or the NAT administrator who is 
> configuring it. 
> 
> -- 
> Saikat
> (who has started seeing glimpses of behave udp emails in his 
> nightmares and wants to make it stop)
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 22 Jun 2005 18:31:43 -0700 (PDT)

Thanks. Good feedback.

Your last point is actually very important. I fully agree with it, and
I think it is why this group keeps on getting into rat-holes.

> Sent: Wednesday, June 22, 2005 13:16
> To: Bryan Ford
> Cc: 'Behave'
> On Wed, 2005-06-22 at 17:24 +0200, Bryan Ford wrote:
> > Implementing EF=I as an option on a NAT
> > that already supports EF=A is trivial.  
> 
> - Implementing EF=A as an option on a NAT that already 
> supports EF=I is
>   not trivial.
> - Even for an EF=A NAT, I don't presume to know how trivial 
> EF=I is; it
>   will require extra code, introduce more bugs, increase 
> complexity and
>   add to the testing/QA overhead. I suppose a NAT vendor is 
> in a better 
>   position to comment on how hard/easy it is to put into a 
> product than
>   either of us. 
> - Even if they do implement it, the configuration option may 
> or may not
>   be convenient. Windows, Linux and BSD currently do not 
> allow the admin
>   to change any NAT behavior (binding, timer, fragment 
> handling etc). A
>   lot of "Zero-configuration" VoIP devices 
> (http://www.siphardware.com/)
>   come bundled with very rudimentary NATs whose sole purpose 
> in life is
>   to shunt VoIP traffic to the device and send everything else down 
>   another interface.
> 
> But most importantly, 
> 
> - The document specifies interoperability standards; not how to
>   implement it. The config option would be nice, but there is no 
>   compelling justification for it -- if security is important 
> do EF=A, 
>   if transparency is do EF=I, Why both? 'It doesn't change anything or
>   is trivial' is not a compelling. If vendors cannot stay "fully
>   compliant" without implementing this one item with a wishy-washy
>   justification, they might as well balk and stop following any of the
>   RECOMMENDED parts since they cannot be fully compliant anyway; which
>   would be a complete disaster.
> 
> -- 
> Saikat
> (who found an interesting, and provocative, article linked 
> off of Slashdot -- 
> http://www.securityfocus.com/columnists/334. Standard
> Disclaimer: this does not necessarily reflect the views of 
> the poster or this mailing list etc. etc.)
>

---

From: "Cullen Jennings" <[email-masked]>
Date: Mon, 1 Aug 2005 06:29:26 -0700 (PDT)

<SPAN 
class=083034012-01082005>sorry accidentally replied instead of reply all on this 
one. 

From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] 
Sent: Sunday, July 31, 2005 12:31 PMTo: 'Francois 
Audet'Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, 
REQ-7

<FONT face=Arial 
color=#0000ff>I have no idea how Bryan can think I would be OK with that. But 
anyways, to clarify, I'm not.
<FONT face=Arial 
color=#0000ff> 
<FONT face=Arial 
color=#0000ff>(obviosly not as chair)
<FONT face=Arial 
color=#0000ff> 

From: Francois Audet [mailto:audet@xxxxxxxxxx] 
Sent: Wednesday, June 22, 2005 2:03 AMTo: 'Cullen 
Jennings'Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, 
REQ-7

Cullen, 
We are waiting for you to tell us what you really meant: 
"SHOULD" or "MAY" in 7a. 
Please say so on the list so we can put this issue to 
rest... 
To refresh your memory, I have: 
 REQ-7: If application transparency is most important, it 
is         
RECOMMENDED that a NAT have an "Endpoint independent filtering" <FONT 
size=2>        behavior. If a more stringent 
filtering behavior is most   
        important, it is RECOMMENDED that a NAT 
have an "Address <FONT 
size=2>        dependent filtering" 
behavior. 
        a) The filtering 
behavior MAY be an option configurable by the <FONT 
size=2>           
administrator of the NAT. 
Bryan is OK with 7, but wants to change the "MAY" to a "SHOULD" 
in 7a, and claims that you are OK with it. 
As you know, I really don't give a &*(*#? at this 
point. 
> -----Original Message----- > 
From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx > [<A 
href="mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx">mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] 
On Behalf Of > Bryan Ford <FONT 
size=2>> Sent: Tuesday, June 21, 2005 12:22 > To: 
Saikat Guha > Cc: 'Behave' <FONT 
size=2>> Subject: Re: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, 
REQ-7 > > <FONT 
size=2>> On Tuesday 21 June 2005 19:07, Saikat Guha wrote: <FONT 
size=2>> > On Tue, 2005-06-21 at 09:59 -0600, Bryan Ford wrote: 
> > > On Thursday 09 June 2005 16:17, Francois Audet 
wrote: > > > 
>        a) The filtering behavior MAY be 
an option > configurable by <FONT 
size=2>> > > > the > > > 
> > > I still feel strongly that the MAY should 
be > > > a SHOULD in the second.  I don't 
recall hearing any > objections from <FONT 
size=2>> > > Cullen or anyone else after my earlier suggestion that we 
> keep the > > > 
SHOULD but change "user configurable" to "configurable by the <FONT 
size=2>> > > administrator of the NAT". > 
> > > I agree with Cullen (below) that changing 
the MAY to should doesn't > > change any 
interoperability issues. Even if "user configurable" is <FONT 
size=2>> > changed to "configurable by the administrator", all of Cullen's 
> > objections still hold. <FONT 
size=2>> > In what way do they still hold?  
As far as I can tell, > Cullen's objections 
> were primarily based on his comment that "In many 
case[s] the > administrator <FONT 
size=2>> of the NAT is very different from the user of it" and 
> therefore it was > 
unreasonable to expect a NAT's behavior to be > 
"user-configurable".  That > statement I agree 
with.  It is entirely reasonable, however, > to 
expect a > NAT's behavior to be 
"administrator-configurable".  Every NAT > on 
the planet > is already "administrator-configurable" 
- even locked-down > NATs supplied by 
> ISPs, which are configured by the ISP's 
administrator > (perhaps before they <FONT 
size=2>> are even shipped to the user).  The problem was merely a 
> minor semantic > 
confusion caused by the distinction between "user" and <FONT 
size=2>> "administrator".  I > always meant 
"administrator-configurable"; it just > accidentally 
came out > "user-configurable" at some point because 
I wasn't thinking > carefully about <FONT 
size=2>> that distinction at the time. > 
> > Changing it to SHOULD/RECOMMENDED in 
REQ-7a > > introduces a hidden recommendation that 
a NAT SHOULD implement both > > filtering 
behaviors (so it can have an option configurable by the <FONT 
size=2>> > admin) ... which is not what REQ-7 says. I support "MAY" in 
REQ-7a. > > That hidden 
recommendation that a NAT SHOULD implement both filtering <FONT 
size=2>> behaviors is precisely the point.  I feel that if a NAT 
> implements EF=A > 
filtering (which is a problematic but reasonable security <FONT 
size=2>> feature), then it > SHOULD also provide a 
way for the NAT's administrator to turn > that 
filtering > feature off.  Since an EF=A NAT 
minus filtering effectively > becomes an EF=I 
> NAT, what we have is a NAT that is configurable for 
either > EF=I or EF=A.  <FONT 
size=2>> This will take an absurdly small amount of implementation 
> effort by the NAT > 
implementor - every NAT on the planet has a zillion > 
configuration options > already; this is just one 
more, and all it does is turn off a > particular 
> security feature that sometimes gets in the way of 
> application connectivity.  <FONT 
size=2>> Can you explain why it is unreasonable or undesirable for NAT 
> vendors to be > expected 
to provide this small but potentially important bit of <FONT 
size=2>> configurability? > <FONT 
size=2>> Bryan > > > 
On Wed, 2005-06-01 at 09:25 -0400, Cullen Jennings wrote: <FONT 
size=2>> > > > a) The filtering behavior SHOULD be a user 
configurable option. > > > <FONT 
size=2>> > > I could deal with this if we change to MAY but strongly 
object to > > > the SHOULD. There are going to 
be devices where this is > difficult. 
> > > There are going to be devices that only 
support one type. In many > > > case the 
administrator of the NAT is very different from > the 
user of > > > it. There is no reason why the WG 
should tell vendors how > to build <FONT 
size=2>> > > this. Having it as MAY or SHOULD does not change any 
> > > interoperability issues between devices. 
Any standards > body should <FONT 
size=2>> > > focus on things that it needs to specify to ensure 
> interoperability. > > 
> Once vendors start down the slipper slope of not being fully 
> > > compliant, pain and suffering will ensue 
- I'd rather avoid that. > > > It's about as 
useful for the draft to say that all NAT > user 
manuals > > > SHOULD be in gender neutral 
language. It has no effect on > > > 
interoperability. I can not see any good come it and I <FONT 
size=2>> can see harm > > > caused by it 
when key vendors that are not fully complaint start > 
> > justifying why it is not useful to be fully complaint <FONT 
size=2>> with BEHAVE. I > > > know it sounds 
weird to care about this, but I would like > to have 
a > > > chance of getting the largest vendor of 
residential and corporate > > > NATs to do this 
and this is not going to help. > 
_______________________________________________ > 
Ietf-behave mailing list > 
Ietf-behave@xxxxxxxxxxxxxxxxxxx > <A 
href="https://list.sipfoundry.org/mailman/listinfo/ietf-behave" 
target=_blank>https://list.sipfoundry.org/mailman/listinfo/ietf-behave