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

From: "Francois Audet" <[email-masked]>
Date: Mon, 23 Aug 2004 09:55:26 -0700 (PDT)

I'm fine with this.

The only issue is that this wording doesn't give any hints at why one
would allow keep Unicast binding open on inbound UDP unicast, and what
the tradeoff are. I think we would need to describe the security aspects
of it (i.e., an interlocutor could keep the binding opened indefinitely
after a conversation).

In other words, I think Cullen's points 1 & 2 are what we really want,
but 3 is acceptable. We just need to figure out wording for the Unicast 
document that will allow us to get there without contradicting ourselves.

I do agree that we should say as little as possible about multicast in the
unicast document. Perhaps we should make it clear in the introduction what
the scope is.

> -----Original Message-----
> From: Dan Wing [mailto:dwing@xxxxxxxxx] 
> Sent: Monday, August 23, 2004 09:44
> To: Cullen Jennings; Audet, Francois [SC100:9T51:EXCH]; 
> Behave; Jiri Kuthan
> Subject: RE: UPD and Multicast scope
> 
> 
> I like (1), because multicast is already handled differently 
> by the NATs -- to do multicast they have to see an IGMP from 
> the Ethernet-attached computer, propagate the IGMP towards 
> the service provider, and set up a NAT binding.
> 
> 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.
> 
> Section X.Y.Z can talk about timeouts being a MUST.  In a 
> glossary we need to define 'unicast traffic' as an IP packet 
> with an IP source unicast address and IP destination unicast address.
> 
> I feel we should be silent on multicast (and probably also 
> IPsec Security Parameters Index (SPI)), so that they can be 
> fully described in their own separate document.
> 
> -d
> 
> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx]
> Sent: Sunday, August 22, 2004 6:50 PM
> To: Francois Audet; Dan Wing; Behave; Jiri Kuthan
> Subject: UPD and Multicast scope
> 
> 
> 
> 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:
> 
> treat multicast traffic differently
> do outbound keep alives in multicast applications
> update timeouts on inbound packets for unicast UDP
> 
> 
> Thoughts on pros/cons of these?
> 
> Cullen
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Aug 2004 10:26:13 -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 9:54 
  AMTo: 'Dan Wing'; 'Cullen Jennings'; 'Behave'; 'Jiri 
  Kuthan'Subject: RE: UPD and Multicast scope
  I'm fine with this. 
  The only issue is that this wording doesn't give any hints at 
  why one would allow keep Unicast binding open on 
  inbound UDP unicast, and what the tradeoff are. I 
  think we would need to describe the security aspects <FONT 
  size=2>of it (i.e., an interlocutor could keep the binding opened 
  indefinitely after a conversation). <SPAN 
  class=125411817-23082004><FONT face=Verdana color=#0000ff 
  size=2> 
<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 
size=2>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=Verdana color=#0000ff 
size=2>-d
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  In other words, I think Cullen's points 1 & 2 are what we 
  really want, but 3 is acceptable. We just need to 
  figure out wording for the Unicast document that will 
  allow us to get there without contradicting ourselves. 
  I do agree that we should say as little as possible about 
  multicast in the unicast document. Perhaps we should 
  make it clear in the introduction what the scope 
  is. 
  > -----Original Message----- > 
  > Behave; Jiri Kuthan > 
  Subject: RE: UPD and Multicast scope > 
  > > I like (1), because 
  multicast is already handled differently > by the 
  NATs -- to do multicast they have to see an IGMP from <FONT 
  size=2>> the Ethernet-attached computer, propagate the IGMP towards 
  > the service provider, and set up a NAT 
  binding. > > What is 
  critical in the base document is that the base BEHAVE <FONT 
  size=2>> document allows incoming-only multicast packets to keep the 
  > NAT binding open.  I suggest the following 
  straw-man wording > in BEHAVE: <FONT 
  size=2>> >     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 <FONT 
  size=2>>     are in section X.Y.Z. <FONT 
  size=2>> > Section X.Y.Z can talk about timeouts 
  being a MUST.  In a > glossary we need to 
  define 'unicast traffic' as an IP packet > with an 
  IP source unicast address and IP destination unicast address. <FONT 
  size=2>> > I feel we should be silent on 
  multicast (and probably also > IPsec Security 
  Parameters Index (SPI)), so that they can be > 
  fully described in their own separate document. > 
  > -d > <FONT 
  size=2>> -----Original Message----- > From: 
  Cullen Jennings [<A 
  href="mailto:fluffy@xxxxxxxxx">mailto:fluffy@xxxxxxxxx] <FONT 
  size=2>> Sent: Sunday, August 22, 2004 6:50 PM > 
  To: Francois Audet; Dan Wing; Behave; Jiri Kuthan > 
  Subject: UPD and Multicast scope > <FONT 
  size=2>> > > Given 
  the advice we got at the meeting, I would be happiest <FONT 
  size=2>> 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 <FONT 
  size=2>> 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: > > treat 
  multicast traffic differently > do outbound keep 
  alives in multicast applications > update timeouts 
  on inbound packets for unicast UDP > 
  > > Thoughts on 
  pros/cons of these? > > 
  Cullen > >