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

From: Kaushik Biswas <[email-masked]>
Date: Tue, 10 Aug 2004 17:20:41 -0700 (PDT)

Nice document. Couple of points below :

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

- REQ 5: Might be a good to recommend the Filtering EF=APD instead of
EF=AP

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. 

Thanks,
Kaushik

At 04:40 PM 8/10/2004 -0700, Francois Audet wrote:

Hi Geoff, 

I fully agree with your comments: the reason we said
"outbound only" is based 
on what we feel is the proper safe behavior for UDP.

We haven't put much tought on TCP so far, and clearly we need to add more 
information on the requirements. 

I don't know what current NATs "outbound" versus "inbound" behavior is for TCP. 
We didn't even cover it in the first version of the draft. Certainly something to 
investigate. 

> -----Original Message----- 
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] 
> Sent: Tuesday, August 10, 2004 16:22 
> To: 'ietf-behave@xxxxxxxxxxxxxxxxxxx' 
> Subject: RE: [Ietf-behave] NAT behave draft 
> 
> 
> This is good data, and is certainly worth bearing in mind, but the 
> underlying exercise is to document what the WG-to-be believes is the 
> _right_ action. 
> 
> For UDP there is the issue of pinhole extension that argues 
> strongly in 
> favour of outbound-only refresh, and it appears that in 
> general NATs are 
> using this mechanism. 
> 
> But for TCP its not so clear to me that an outbound only is 
> so necessary. 
> Cullen's survey was UDP-based, and I've not seen any other 
> data here. Have 
> you surveyed NAT implementations regarding the refresh time 
> trigger for 
> TCP? Do they differ from UDP? 
> 
> I was quietly thinking to myself that in the case of TCP a 
> bidrectional 
> timer refresh trigger would make more sense than outbound 
> only, and I was 
> wondering if that happens in NATs today. 
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 11 Aug 2004 03:01:30 -0700 (PDT)

At 02:22 AM 8/11/2004, Kaushik Biswas wrote:
>- 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 think the minimum MUST is that outbound refreshes do keep UDP bindings 
alive for some minimum time. That allows for a combination of NAT logic
(open up binding if a client desires to communicate) with client's
interest to keep the same binding as long as it is active. Not doing
so (reported occurences) breaks applications.

The procedural question to me is how far beyond minimum requirements we wish to 
go.

>- REQ 5: Might be a good to recommend the Filtering EF=APD instead of EF=AP
>
>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. 

See ICE -- it tries to determine IP connectivity in end-2-end manner. That's 
being
pursued in MMUSIC WG.

-jiri

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 11 Aug 2004 11:13:20 -0700 (PDT)

OK. I'll capture it in the draft.

> From: Melinda Shore [mailto:mshore@xxxxxxxxx] 
> Sent: Wednesday, August 11, 2004 04:21
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> Subject: Re: [Ietf-behave] NAT behave draft
> 
> 
> 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: "Francois Audet" <[email-masked]>
Date: Fri, 13 Aug 2004 15:51:52 -0700 (PDT)

Agree with Jonathan. 

As stated in the meeting, I will make it clear in the next revision that we are covering 
the inherent "filtering" behavior of NAT, but that "Firewalling" is out-of-scope (as per
the charter).

> From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxxxxxxxx] 
> Sent: Friday, August 13, 2004 12:31
> To: Melinda Shore
> Cc: Audet, Francois [SC100:9T51:EXCH]; 
> 'ietf-behave@xxxxxxxxxxxxxxxxxxx'
> 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.
> -- 
> 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: "Francois Audet" <[email-masked]>
Date: Mon, 16 Aug 2004 15:18:54 -0700 (PDT)

> So from my point of view, the draft should require oubound 
> packets to refresh the NAT binding (since it is important for 
> functionality), but only give recommendations on inbound packets. 

Is that for both TCP and UDP, or just for UDP?

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 Aug 2004 15:28:23 -0700 (PDT)

> Multicast is UDP; I expect you mean to focus this on unicast UDP.

Yes.

> > The intent is not to "break" multicast, but we should certainly not 
> > introduce issues just for multicast.
> 
> If we only require NATs keep their bindings open for outgoing 
> UDP packets, it means multicast won't work.
> 
> > Of course, I'm assuming that somehow it is possible to allow for 
> > multicast without requiring bidirectional or inbound 
> binding for UDP. 
> > (I'm not sure on this point, not being a expert on multicast).
> 
> Me, neither, but an off-list conversation confirmed that it 
> is possible.

So that type of information should be in the second document, provided
that it doesn't conflict with the first one.

> Except that widespread behavior isn't documented in any IETF 
> document, at least not to my knowledge.  What other behaviors 
> are necessary for UDP applications (games, VoIP, etc.) to 
> work over NATs?  It would be useful to collect those into a 
> document to provide guidance to UDP application developers 
> who hope to work with a BEHAVE-compliant NAT.  Otherwise 
> they'll re-invent the same solution or, worse, invent a 
> different solution which works with the specific NATs they're 
> testing with and fail with other NATs in the market they 
> haven't (yet) seen.

I agree 100%.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 23 Aug 2004 08:50:38 -0700 (PDT)

Let's stick with the term NAT.

> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx] 
> Sent: Sunday, August 22, 2004 18:53
> To: Harald Welte; Dan Wing
> Cc: Behave
> On 8/18/04 2:11 PM, "Harald Welte" <laforge@xxxxxxxxxxxxx> wrote:
> 
> > Router
> > Gateway
> > Bridge
> > 
> > (where the last three are most likely quite well-defined 
> already, so 
> > it oculd just reference them).
> 
> Oh the difference between a Router, Switch, and Bridge is 
> something that can consume many beers :-)
> 
> 
> https://list.sipfoundry.org/mailman/listinf> o/ietf-behave
>