Subject: RE: [Ietf-behave] NAT behave draft

From: "Francois Audet" <[email-masked]>
Date: Tue, 10 Aug 2004 18:04:53 -0700 (PDT)

<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  
  <FONT 
  face=Tahoma size=2>-----Original Message-----From: Kaushik Biswas 
  [mailto:kbiswas@xxxxxxxxx] Sent: Tuesday, August 10, 2004 
  17:22To: Audet, Francois [SC100:9T51:EXCH]Cc: 'Geoff 
  Huston'; 'ietf-behave@xxxxxxxxxxxxxxxxxxx'Subject: RE: 
  [Ietf-behave] NAT behave draft
  Nice document. Couple of points below :<SPAN 
  class=119382700-11082004><FONT face=Arial color=#800000 
  size=2>
<FONT face=Arial color=#800000 
size=2>Thanks. 
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  - REQ 4: Don't think we should not make NAT timer "outbound refresh" a 
  MUST. We can suggest a minimum timeout value, and let the NATs decide whether 
  they want to do "bidirectional", "inbound" or "outbound" refresh. Besides this 
  doesn't hamper the traversal-mechanisms & is a nice-to-have wrt 
  NAT-architecture.
<FONT face=Arial color=#800000 
size=2>I agree that Bidirectional will "work" as well as the "outbound" only. 

<FONT face=Arial color=#800000 
size=2> 
<FONT face=Arial color=#800000 
size=2>However, I am concerned that it would enable somebody you have been 
receiving media from to to keep that binding alive even after the call has 
been torn down (maliciously or not), by sending media to you periodically. I 
personally think this is somewhat of a security issue.
<FONT face=Arial color=#800000 
size=2> 
<FONT face=Arial color=#800000 
size=2>On a subsequent genuine session, you may be receiving the garbage media 
stream interleaved with the real and active new one.
<FONT face=Arial color=#800000 
size=2> 
<FONT face=Arial color=#800000 
size=2>So, I'm a bit reluctant on that one.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
   - REQ 5: Might be a good to 
  recommend the Filtering EF=APD instead of EF=AP
<FONT face=Arial color=#800000 
size=2>I don't personnally have a problem with this recommendation. However, I 
believe some have told us that it might be an issue with certain gaming 
protocols. Perhaps we should flag it as an opened issue. In any case, I think we 
have a concensus that both are acceptable, it is matter of deciding which is 
recommended.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
   After agreeing upon the 
  basic-requirements we can try to have the respective traversal-mechanisms have 
  some technique to figure out whether the path from A->B traversing n-NATs 
  are indeed all following the basic-requirements (as is required for 
  traversal-mechanism to work). Sort of making this is a MUST for 
  traversal-mechanisms rather than relying upon the network. This way there can 
  be a fall-back mechanism from traversal-mechanisms to "traditional" mechanisms 
  like ALG-processing. This can arise in scenario whereby the traversal 
  mechanism, say X, is working just fine but say 2 companies merged and newly 
  merged company doesn't have NATs following the basic-requirements as required 
  for traversal-mechanism: X to work. Basically a mixed network. In such case if 
  communication is to be between these two, then "traditional" SIP ALG might 
  need to be used. 
<FONT face=Arial color=#800000 
size=2>This is essentially what ICE attempts to do, although you seem to want to 
widen the scope to alternatives that are not used by ICE (namely, 
ALGs).
<FONT face=Arial color=#800000 
size=2> 
<FONT face=Arial color=#800000 
size=2>I believe this is very important, but I don't believe that it is in the 
scope of the BEHAVE group since we are not looking at the network and SIP 
clients aspects. 
<FONT face=Arial color=#800000 
size=2> 
<FONT face=Arial color=#800000 
size=2>I believe that the nat-scenarios document is being revised in SIPPING. 
Perhaps this is where this should be addressed: <A 
href="http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-nat-scenarios-03.txt">http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-nat-scenarios-03.txt
<FONT face=Arial color=#800000 
size=2>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 11 Aug 2004 04:21:16 -0700 (PDT)

On Tuesday, August 10, 2004, at 09:01 PM, Francois Audet wrote:
However, I am concerned that it would enable somebody you have been 
receiving media from to to keep that binding alive even after the call 
has been torn down (maliciously or not), by sending media to you 
periodically. I personally think this is somewhat of a security issue.
It would be, depending on whether or not you think that NAT is security
technology and that directionality is a security property.  I could go
either way - I personally don't think of NATs as security devices, but
that's how they're very often used in the real world.  It would 
probably be
useful to include a few sentences explaining the issue.

Melinda

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Aug 2004 12:23:25 -0700 (PDT)

inline.

Francois Audet wrote:

    -----Original Message-----
    *From:* Kaushik Biswas [mailto:kbiswas@xxxxxxxxx]
    *Sent:* Tuesday, August 10, 2004 17:22
    *To:* Audet, Francois [SC100:9T51:EXCH]
    *Cc:* 'Geoff Huston'; 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
    *Subject:* RE: [Ietf-behave] NAT behave draft
    Nice document. Couple of points below :

Thanks. 

    - REQ 4: Don't think we should not make NAT timer "outbound refresh"
    a MUST. We can suggest a minimum timeout value, and let the NATs
    decide whether they want to do "bidirectional", "inbound" or
    "outbound" refresh. Besides this doesn't hamper the
    traversal-mechanisms & is a nice-to-have wrt NAT-architecture.
I agree that Bidirectional will "work" as well as the "outbound" only.
 
However, I am concerned that it would enable somebody you have been 
receiving media from to to keep that binding alive even after the call 
has been torn down (maliciously or not), by sending media to you 
periodically. I personally think this is somewhat of a security issue.
The other issue is determinism. The point of the behave effort is to 
define a well-understood baseline set of behaviors that applications can 
depend on. In particular, I think a good metric is that, if an 
application has to do something quite different if a NAT exhibits 
behavior X as opposed to behavior Y, we should specify, at MUST 
strength, the behavior. Otherwise, we are right back to where we are now.

As it pertains to this topic, if an application doesn't know which 
direction a NAT uses to keep bindings active, and it guesses wrong, it 
won't get service. We want to avoid that. Indeed, if you don't specify 
which direction, an app will need to assume the worst case and refresh 
both....

     After agreeing upon the basic-requirements we can try to have the
    respective traversal-mechanisms have some technique to figure out
    whether the path from A->B traversing n-NATs are indeed all
    following the basic-requirements (as is required for
    traversal-mechanism to work). Sort of making this is a MUST for
    traversal-mechanisms rather than relying upon the network. This way
    there can be a fall-back mechanism from traversal-mechanisms to
    "traditional" mechanisms like ALG-processing. This can arise in
    scenario whereby the traversal mechanism, say X, is working just
    fine but say 2 companies merged and newly merged company doesn't
    have NATs following the basic-requirements as required for
    traversal-mechanism: X to work. Basically a mixed network. In such
    case if communication is to be between these two, then "traditional"
    SIP ALG might need to be used. 

This is essentially what ICE attempts to do, although you seem to want 
to widen the scope to alternatives that are not used by ICE (namely, ALGs).
ALGs are covered by ICE, although not explicitly. If an ALG should 
attempt to rewrite the SDP, that rewritten address becomes just another 
choice which can be tried.

I believe this is very important, but I don't believe that it is in the 
scope of the BEHAVE group since we are not looking at the network and 
SIP clients aspects.
Agree.

I believe that the nat-scenarios document is being revised in SIPPING. 
Perhaps this is where this should be addressed: 
http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-nat-scenarios-03.txt
Yes, I think we should have a use case that shows the interaction with a 
B2BUAWM with ICE.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@xxxxxxxxxxxxxxx                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Aug 2004 12:32:43 -0700 (PDT)

inline.

Melinda Shore wrote:

It would be, depending on whether or not you think that NAT is security
technology 
I think that is an important question. Francois and Cullen's draft does 
a good job in trying to pull apart the filtering and binding aspects of 
NAT behavior, but they are ultimately linked. The lack of a binding 
inherently creates a filtering rule that would prohibit any inbound 
communications to the host. Since bindings are created by outbound 
traffic, NATs have an inherent filtering property which prohibit inbound 
packets to a host unless it has communicated outward. I think it is 
widely accepted that there are security properties afforded by this kind 
of behavior. I think we should avoiding calling this a "firewall", since 
the filtering is a byproduct of the fundamental property of NAT, rather 
than an expression of operator policy.

-Jonathan R.