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

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

. 
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    I 
    agree that needs to be in the document -- for all of the MUSTs and 
    SHOULDs.
  <FONT face=Verdana 
  color=#0000ff>However, there isn't a risk with someone keeping 
  the binding open indefinately; the risk is that an open binding will cause 
  packets to be sent to a host that (a) has no application listening on that 
  port [and sends back an ICMP message] or (b) has a different application 
  listening on that port.  Those problems can be resolved with (1) a timer, 
  (2) using new DHCP leases to break old NAT bindings, or (3) using some 
  number of ICMP 'port unreachable' messages from the PC to close the NAT 
  binding (akin to TCP RSTs and FINs which help to quickly close NAT 
  bindings).  There are probably a few other solutions, too, but these came 
  to mind immediately.  A timer is easy, but doesn't quite close things up 
  neatly unless the timer is very short -- and a short timer means NAT 
  keepalives have to be quite aggressive, which leads to scaling 
  difficulties.  Perhaps these fancier techniques, though, shouldn't be in 
  BEHAVE?<FONT face=Arial 
  color=#800000> 
<FONT 
size=2>What 
worries me is (b). As an example, I may hang up, and phone somebody 
else right away. If my phone uses the same UDP port for every call (which 
many phones do), then I could be receiving from two places simultaneously 
(the real new call, and the other call that didn't hang up properly), with no 
good way for the phone to figure out which one is the right 
one.
<FONT 
size=2><FONT face=Arial 
color=#800000>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.
<FONT face=Arial color=#800000 
size=2>The timer approach works only if the 
outgoing traffic refreshes the binding but not the incoming (which is what we 
are discussing).
<FONT face=Arial color=#800000 
size=2>The ICMP won't work if the phones want to 
use the same port.
<FONT face=Arial color=#800000 
size=2>As you say, the techniques you are 
describing are valid, but not NAT-specific, and therefore not for BEHAVE (they 
could be described in a client document of 
course).
<FONT face=Arial color=#800000 
size=2>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.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Aug 2004 10:57:35 -0700 (PDT)

<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <FONT face=Tahoma 
  size=2>-----Original Message-----From: Francois Audet 
  [mailto:audet@xxxxxxxxxxxxxxxxxx]Sent: Monday, August 23, 2004 
  10:38 AMTo: 'Dan Wing'; 'Cullen Jennings'; 'Behave'; 'Jiri 
  Kuthan'Subject: RE: UPD and Multicast scope
  . 
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
    <BLOCKQUOTE dir=ltr 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
      <FONT face=Verdana color=#0000ff 
      size=2>I agree that needs to be in the document -- for all of the MUSTs 
      and SHOULDs.
    <FONT face=Verdana 
    color=#0000ff>However, there isn't a risk with someone keeping 
    the binding open indefinately; the risk is that an open binding will cause 
    packets to be sent to a host that (a) has no application listening on that 
    port [and sends back an ICMP message] or (b) has a different application 
    listening on that port.  Those problems can be resolved with (1) a 
    timer, (2) using new DHCP leases to break old NAT bindings, or (3) 
    using some number of ICMP 'port unreachable' messages from the PC to 
    close the NAT binding (akin to TCP RSTs and FINs which help to quickly close 
    NAT bindings).  There are probably a few other solutions, too, but 
    these came to mind immediately.  A timer is easy, but doesn't quite 
    close things up neatly unless the timer is very short -- and a short timer 
    means NAT keepalives have to be quite aggressive, which leads to scaling 
    difficulties.  Perhaps these fancier techniques, though, shouldn't be 
    in BEHAVE?<FONT face=Arial 
    color=#800000> 
  <FONT face=Verdana 
  color=#0000ff><FONT face=Arial 
  color=#800000>What worries me is (b). As an example, I 
  may hang up, and phone somebody else right away. If my phone uses the 
  same UDP port for every call (which many phones do), then I could be 
  receiving from two places simultaneously (the real new call, and the other 
  call that didn't hang up properly), with no good way for the phone to figure 
  out which one is the right one.<FONT 
  face=Verdana 
  color=#0000ff> 
<SPAN 
class=012262917-23082004><SPAN 
class=894205217-23082004>So if you don't have a NAT at all, this application 
would misbehave, right?  That is, following the scenario above and 
without a NAT anywhere you would hear the previous call's 
audio.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <FONT face=Verdana 
  color=#0000ff><FONT face=Arial 
  color=#800000><SPAN 
  class=894205217-23082004> 
  <FONT face=Verdana 
  color=#0000ff><FONT face=Arial 
  color=#800000>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.<FONT face=Verdana 
  color=#0000ff> 
<SPAN 
class=012262917-23082004><SPAN 
class=894205217-23082004>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.<SPAN 
class=125411817-23082004><SPAN 
class=012262917-23082004><SPAN 
class=894205217-23082004> 
<SPAN 
class=012262917-23082004><FONT face=Verdana 
color=#0000ff size=2>I do agree 
expecting DHCP isn't ideal.  Instead, you could notice a new MAC 
address for a new host.
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <FONT face=Arial 
  color=#800000 size=2>The timer approach works 
  only if the outgoing traffic refreshes the binding but not the incoming (which 
  is what we are discussing).
  <SPAN 
  class=012262917-23082004>The ICMP won't work if the phones want 
  to use the same port.<FONT face=Verdana 
  color=#0000ff> 
<SPAN 
class=012262917-23082004><FONT 
face=Verdana color=#0000ff>The timer only solves the scenario you're describing 
if the phone stays onhook for the timer duration.  So if I'm calling 
"quickly", and the timer is a very aggressive 10 seconds, the timer won't be 
effective to resolve this 
scenario. 
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <FONT face=Arial 
  color=#800000 size=2>As you say, the techniques 
  you are describing are valid, but not NAT-specific, and therefore not for 
  BEHAVE (they could be described in a client document of 
  course).
  <SPAN 
  class=012262917-23082004>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.<FONT 
  face=Verdana 
color=#0000ff> 
<SPAN 
class=012262917-23082004><FONT 
face=Verdana color=#0000ff>I agree.  Let's continue evolving strawman 
text.
<SPAN 
class=012262917-23082004><FONT 
face=Verdana color=#0000ff>-d
<SPAN 
class=012262917-23082004><SPAN 
class=894205217-23082004>