Subject: RE: [Ietf-behave] UPD and Multicast scope

From: "Francois Audet" <[email-masked]>
Date: Mon, 23 Aug 2004 10:29:18 -0700 (PDT)

I 
think what we are saying is that when we do publish the multicast document, it 
can not contradict the unicast document.
<FONT face=Arial color=#800000 
size=2> 
The 
hooks must be in place in the unicast document so that a NAT manufacturer may 
decide after having produced a unicast-support compliant NAT, to enhance it for 
multicast-support compliancy, without contradicting the first 
RFC.
<FONT face=Arial color=#800000 
size=2> 
As a 
concrete example:
  <FONT face=Arial color=#800000 
  size=2>Vendor makes NAT that support unicast UDP with outgoing binding refresh 
  only. Spec says "for unicast UDP, RECOMMEND outgoing binding only". Complies 
  with first RFC. Very secure.
  6 
  months later, the multicast document goes out. It says "for multicast UDP, 
  SHALL support blablabla". Vendor adds multicast support. Complies with second 
  RFC, still complies with first RFC, still very secure.
A 
second concrete example:
  <FONT face=Arial color=#800000 
  size=2>Vendor makes NAT that support unicast UDP with both outgoing and 
  incoming binding refresh. Complies with first RFC, but not as secure as 
  previous example.
  6 
  months later the multicast document goes out. Vendor already supports 
  multicast. Vendor updates the print on the boxes as it complies with second 
  RFC. Of course, if we find out other things that are missing for multicast 
  (which is likely), vendor may still have to do some work before claiming 
  support for multicast.
<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: Spencer Dawkins 
  [mailto:spencer@xxxxxxxxxxxxx] Sent: Monday, August 23, 2004 
  04:30To: IETF Behave Mailing ListSubject: Re: 
  [Ietf-behave] UPD and Multicast scope
  I'm not disagreeing on the "work on unicast UDP first" 
  strategy, but I do have a question.
   
  If I understand the justification for BEHAVE, the idea is to 
  have BCP-strength specifications that vendors and operators will use, and then 
  (they will most likely) claim "BCP 110" (more likely "RFC 4112", but that's a 
  NEWTRK problem) compliance.
   
  If we don't work on multicast at this time, I think we're 
  saying "we don't care if people break multicast now - if their NATs drop all 
  multicast traffic, they can stilll say they comply with IETF BCPs for 
  NAT, and that's OK".
   
  Is that what we're saying?
   
  Spencer
  <BLOCKQUOTE 
  style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    ----- Original Message ----- 
    <DIV 
    style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black">From: 
    Cullen Jennings 
    
    To: <A title=audet@xxxxxxxxxxxxxxxxxx 
    href="mailto:audet@xxxxxxxxxxxxxxxxxx">Francois Audet ; <A 
    title=dwing@xxxxxxxxx href="mailto:dwing@xxxxxxxxx">Dan Wing ; <A 
    title=ietf-behave@xxxxxxxxxxxxxxxxxxx 
    href="mailto:ietf-behave@xxxxxxxxxxxxxxxxxxx">Behave ; <A 
    title=jiri@xxxxxxxxx href="mailto:jiri@xxxxxxxxx">Jiri Kuthan 
    Sent: Sunday, August 22, 2004 8:49 
    PM
    Subject: [Ietf-behave] UPD and 
    Multicast scope
    <SPAN 
    style="FONT-SIZE: 14px">Given the advice we got at the meeting, I would 
    be happiest to propose we do the "UDP Unicast" stuff in one of our first 
    documents then do the "Multicast" stuff in a later document. That 
    said, I think that considering how our future work might break the UDP 
    Unicast work is completely appropriate. We probably need some clue of how we 
    might solve the multicast timeouts issues when we get to them and if that 
    would require changers to the UDP document we need to contemplate that 
    now.I can see several discussion paths we might 
    pursue:
    
      <SPAN 
      style="FONT-SIZE: 14px">treat multicast traffic differently 
      <SPAN 
      style="FONT-SIZE: 14px">do outbound keep alives in multicast applications 
      
      <SPAN 
      style="FONT-SIZE: 14px">update timeouts on inbound packets for unicast 
      UDP<SPAN 
    style="FONT-SIZE: 14px">Thoughts on pros/cons of 
    these?Cullen

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Aug 2004 18:07:21 -0700 (PDT)

> On Mon, Aug 23, 2004 at 10:57:33AM -0700, Dan Wing wrote:
> >   The DHCP approach doesn't seem realistic to me: you might not even be
> > using DHCP in the first place, and it would be quite slow.
> >
> > What's slow -- getting an IP address via DHCP?  My Linksys box
> > responds to
> > DHCP requests pretty quickly in my experience, although I have
> > never timed it.
>
> It don't like the idea of requiring/recommending NAT devices use DHCP in
> their internal network.  There are lots of setups which use static IP's,
> and that's perfectly fine.

Fine - I agree with that.

But I'm still not understand what is slow.  To catch everyone else up,
Francois Audet had written:

  The DHCP approach doesn't seem realistic to me: you might not even be
  using DHCP in the first place, and it would be quite slow.

And I asked what is "quite slow".

> >   The timer approach works only if the outgoing traffic refreshes the
> > binding but not the incoming (which is what we are discussing).
> >
> >   The ICMP won't work if the phones want to use the same port.
>
> so why don't we just require the BEHAVE-compliant protocols to not reuse
> the same UDP port for a given time 'X'.  'X' is to be defined larger
> than the timeout for inbound NAT refreshing, so we're guaranteed that
> the internal host will at least send ICMP port unreachable once.

When such behavior occurs on a host, I don't see the new side-effect
that a NAT causes.  If there is a side effect that a NAT causes, could
you or Francois describe it?

-d

> >   I still think that we should put something in BEHAVE that
> > encourage NAT
> > vendors to minimize the chances of ports being kept opened from
> > the outside.
>
>
>
> --
> - Harald Welte <laforge@xxxxxxxxxxxx>
http://www.gnumonks.org/
============================================================================
Programming is like sex: One mistake and you have to support it your
lifetime

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Aug 2004 10:03:57 -0700 (PDT)

> But I'm still not understand what is slow.  To catch everyone 
> else up, Francois Audet had written:
> 

Perhaps it doesn't matter how fast it is.

I don't think using DHCP is the way to address this problem anyways. As
mentioned above, static configurations are used. I think we can
put that issue to rest.

> > >   The timer approach works only if the outgoing traffic refreshes 
> > > the binding but not the incoming (which is what we are 
> discussing).
> > >
> > so why don't we just require the BEHAVE-compliant protocols to not 
> > reuse the same UDP port for a given time 'X'.  'X' is to be defined 
> > larger than the timeout for inbound NAT refreshing, so we're 
> > guaranteed that the internal host will at least send ICMP port 
> > unreachable once.
> 
> When such behavior occurs on a host, I don't see the new 
> side-effect that a NAT causes.  If there is a side effect 
> that a NAT causes, could you or Francois describe it?

I'm not sure I'm following the train of thought for this question
(and the previous suggestion about no re-using the same port).

Can you elaborate?

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Sep 2004 10:08:57 -0700 (PDT)

On 8/27/04 3:49 PM, "Harald Welte" <laforge@xxxxxxxxxxxx> wrote:

> On Mon, Aug 23, 2004 at 09:44:16AM -0700, Dan Wing wrote:
>> What is critical in the base document is that the base BEHAVE document
>> allows incoming-only multicast packets to keep the NAT binding open.  I
>> suggest the following straw-man wording in BEHAVE:
>> 
>>     For unicast traffic, a binding MUST remain open if a UDP packet is sent
>>     from an inside address to an outside address. Additionally, unicast UDP
>>     bindings MAY be kept open if a UDP packet is received from the
>>     outside to the inside. Requirements for timing out these bindings
>>     are in section X.Y.Z.
> 
> I totally agree with this wording.

I like this wording and it nicely leaves the door open for whatever we have
happen in the multicast document.