Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05)

From: "Francois Audet" <[email-masked]>
Date: Thu, 27 Apr 2006 09:16:43 -0700 (PDT)

You should be aware that this means that products that have long
timers will not work with SIP or most other VoiP/Multimedia protocols.

I'm worried that if we can't find a middleground, what will happen is
that there will be two types of firewalls:
- The ones that work with SIP and VoIP (BEHAVE-compliant)
- The ones that don't (not BEHAVE-compliant)

It seems from the list that the rough concensus is a 2 minute timer.

> -----Original Message-----
> From: Ariel Shaqed (Scolnicov) [mailto:ascolnic@xxxxxxxxxxxxxx] 
> Sent: Wednesday, April 26, 2006 23:20
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Cc: Pyda Srisuresh; Audet, Francois [SC100:3055:EXCH]; Magnus 
> Westerlund
> Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution 
> comments on draft-ietf-behave-nat-udp-05)
> 
> 
> On Wednesday 26 April 2006 03:51, Pyda Srisuresh wrote:
> > 2 Minutes works for me.
> 
> 2 minutes is probably too much, as I explained in my 
> <200604251129.05560@kmail-ckp>.  The requirement to keep 
> state for all 
> ports is quite heavy on a large NAT.  Additionally, whether 
> we like it or 
> not, firewall traversal requires keepalives.  It is often 
> unacceptable for 
> firewalls to keep state for all UDP connections -- to 
> registered ports -- 
> for 2 minutes.
> 
> > regards,
> > suresh
> >
> > --- Francois Audet <audet@xxxxxxxxxx> wrote:
> > > I will point out that ALL our drafts had a timeout of 2 minutes.
> > >
> > > It's only the -05 draft where we shortened it to 1 minute.
> > >
> > > The concensus of the group had always been 2 minutes.
> 
> And 60 seconds is better than requiring that all UDP 
> connections last for 
> at least 2 minutes.
> 
> > >
> > > > -----Original Message-----
> > > > From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx]
> > > > Sent: Tuesday, April 25, 2006 07:17
> > > > To: Magnus Westerlund
> > > > Cc: Audet, Francois [SC100:3055:EXCH]; Cullen Jennings; 
> > > > dwing@xxxxxxxxx; Behave
> > > > Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution 
> > > > comments on draft-ietf-behave-nat-udp-05)
> 
> [...snipped...]
> 
> -- 
> Ariel Scolnicov.
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 1 May 2006 18:18:09 -0700 (PDT)

I'll make the changes.

> From: Dan Wing [mailto:dwing@xxxxxxxxx] 
> Sent: Monday, May 01, 2006 15:18
> To: 'Pyda Srisuresh'; 'Magnus Westerlund'
> Cc: 'Cullen Jennings'; 'Behave'; Audet, Francois [SC100:3055:EXCH]
> Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution 
> > Magnus and Dan,
> > I had suggested that Reqs 12, 13 and 14 be dropped from the
> > UDP draft as they are ICMP related and not unique to UDP. 
> > Any reason why these should remain in the UDP draft? Thanks.
> 
> I agree REQ-12 (receiving ICMP should not terminate an 
> existing NAT binding) should be removed from the UDP draft 
> and put into the ICMP draft.
> 
> REQ-13 (fragment outgoing packets) is restating a router 
> requirement. I agree it isn't unique to UDP.  However, it 
> seems useful to have in the UDP document because it's 
> necessary for Path MTU Discovery, and many implementors only 
> consider Path MTU Discovery with TCP (and not UDP).  With 
> things like video, UDP packets will need to be as large as 
> possible and it's important that NATs understand the need to 
> implement this function.  If this requirement is generalized 
> to cover all IP protocols (not just UDP) and appears in the 
> ICMP draft, though, that is a reasonable separation of scope for me.
> 
> I agree REQ-14 (support receiving out of order IP fragments) 
> isn't unique to UDP, but we don't have an "all protocols" 
> document in our charter.  This requirement goes hand-in-hand 
> with REQ-13 and with endpoints that don't perform Path MTU 
> Discovery for UDP flows.
> 
> -d
> 
> > 
> > regards,
> > suresh
> > 
> > --- Dan Wing <dwing@xxxxxxxxx> wrote:
> > 
> > > Magnus Westerlund wrote:
> > > 
> > > > Francois Audet wrote:
> > > > Reviewing the discussion that resulted from me raising 
> this issue
> > > > results in me seeing rough consensus for having the value at 
> > > > 2 minutes.
> > > > 
> > > > I think that resolves all the topics I raised in relation
> > to my AD
> > > > comments on the UDP draft.
> > > > 
> > > > I am not yet certain if the new topic raised about consistent
> > > > handling when the NAT has run out of resources is intended to 
> > > > affect the NAT UDP draft or not.  Please clarify that!
> > > 
> > > Consensus seems to be that it would belong in the ICMP draft.
> > > 
> > > > I do like to be have an updated draft as soon as possible
> > and going
> > > > forward in the process towards publication.
> > > 
> > > -d
> > > 
> 
>