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

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

Hi Dan,

I think we need Multicast & other specific requirements, to be done in a later document.
Fist document could be focused on UDP only.

The intent is not to "break" multicast, but we should certainly not introduce 
issues just for multicast.

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). Perhaps someone can clarify.

For the "music-on-hold" issue, my take is that the sending of probe packets for
that purpose is quite widespread, so I don't think it is an issue.

> -----Original Message-----
> From: Dan Wing [mailto:dwing@xxxxxxxxx] 
> Sent: Wednesday, August 18, 2004 14:54
> To: Harald Welte
> Cc: Audet, Francois [SC100:9T51:EXCH]; ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Ietf-behave] NAT behave draft
> 
> 
> > > Then let me provide two examples:
> > > [...]
> >
> > Sorry, again I'm fighting with my own wording.
> >
> > Given the current draft's spirit that only outbound packets should 
> > refresh the NAT binding, I see no way how a NAT implementation that 
> > also refreshes for inbound packets could break anything 
> (that wasn't 
> > already broken by the draft's requirement).
> >
> > So independent of the (important) policy question whether 
> inbound or 
> > bidirectional packets should refresh (which I'm not even trying to
> > answer):  If the draft is in favour of incoming-only as 
> requirement, 
> > it
> 
> (I believe you intended to write "outgoing-only" in the line above.)
> 
> > should leave bidirectional as a possibility to the implementor.
> 
> Okay, I now understand what you're saying.
> 
> 
> My point is that if the BEHAVE document is silent and only 
> requires outbound NAT binding refresh, two applications 
> (multicast and music-
> on-hold) won't work.  I believe we can workaround 
> music-on-hold so that it works with outbound-only NAT refresh 
> (the workaround is to leak packets in violation of recvonly), 
> but I don't believe we can workaround multicast.
> 
> > > > 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.
> > >
> > > I'm feeling we're going to need a companion BEHAVE 
> document for how 
> > > voice over IP and video over IP endpoints need to behave 
> in face of 
> > > a BEHAVE-compliant NAT.
> >
> > Sounds reasonable to me.
> 
> Is this group's consensus that we allow multicast to be 
> broken by BEHAVE- compliant NATs?  If so, we could have a 
> separate specification that describes how a BEHAVE-compliant 
> NAT could also support multicast.  In my opinion a separate 
> document for multicast, IPsec, and other oddball things 
> (Router Alert Option) might be the best way to allow BEHAVE 
> to process quickly around UDP and ICMP without being held 
> back with more complicated and less-common protocols.
> 
> > Maybe accompany it by another draft on terminology?  I 
> really dislike 
> > the cofusion mostly caused by equipment vendors calling 
> their devices 
> > 'access routers' if they really are fully-fledged NAT/NAPT 
> + Stateful 
> > Packet Filter devices..
> >
> > NAT
> > NAPT
> > Masquerading
> > Firewall
> > Packet filter
> > Stateful Packet Filter
> > Stateless Packet Filter
> > Router
> > Gateway
> > Bridge
> >
> > (where the last three are most likely quite well-defined 
> already, so 
> > it oculd just reference them).
> 
> We could define those terms, but I don't anticipate that 
> changing product packaging or advertising.
> 
> -d
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 18 Aug 2004 15:21:49 -0700 (PDT)

> Fist document could be focused on UDP only.

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

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

> Perhaps someone can clarify.
> For the "music-on-hold" issue, my take is that the sending of probe
> packets for that purpose is quite widespread, so I don't think it is
> an issue.

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.

-d

---

From: Harald Welte <[email-masked]>
Date: Thu, 19 Aug 2004 01:35:30 -0700 (PDT)

> I think we need Multicast & other specific requirements, to be done in

Mh, why is that?

Multicast requirements are split in two parts:

1) in 99.9% of all cases udp-based payload
2) IGMP multicast subscriptions

The only requirement for '1' that I can see, is the requirement of
having inbound-only UDP packets refresh the NAT binding.

Since it was argued multiple times that inbound refresh is needed for
other applications, too - the draft could just demand bidirectional
refresh. This would automatically give us 50% of the functionality we
need for multicast listeners behind the NAT.

> The intent is not to "break" multicast, but we should certainly not
> introduce issues just for multicast.

My take on this is, that as soon as we do not require inbound packets to
refresh the NAT binding, we

> 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). Perhaps
> someone can clarify.

Not without some ugly kludge like having a multicast listener sending
back bogus packets to the multicast group, i.e. every other listener.
(because the NAT treats multicast just like unicast and needs to see the
 same source/destination tuple)

Firsty, this would break existing multicast applications and requires
specifically BEHAVE compliant designed applications.  Secondly, you
would flood all the group members with your keepalive packets ;(

> For the "music-on-hold" issue, my take is that the sending of probe packets
> for that purpose is quite widespread, so I don't think it is an issue.

I think this issue is a question of whether this group wants to 

a) focus on making NAT's as invisible and interoperable with existing
   applications 

or 

b) draft some specific requirements for NAT's and application designers to
   make future applications interoperate better with behave-compliant NAT's.

If we favor 'a', then we cannot require any keepalive packets either in
the unicast nor in the multicast case and must require inbound refresh.

-- 
- Harald Welte <laforge@xxxxxxxxxxxxx>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie
Attachment:
signature.asc

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 19 Aug 2004 14:11:39 -0700 (PDT)

Harald Welte wrote:

Not without some ugly kludge like having a multicast listener sending
back bogus packets to the multicast group, i.e. every other listener.
(because the NAT treats multicast just like unicast and needs to see the
 same source/destination tuple)
I don't see the problem here, actually. Why can't we specify different 
keepalive rules for multicast and unicast? The two are readily 
differentiated in the NAT by the IP address. For multicast, there 
basically is a "keepalive" from the inside to the out - IGMP. If the 
user decides to leave the group, packets won't be forwarded, and there 
is no problem.

-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