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

From: "Francois Audet" <[email-masked]>
Date: Tue, 25 Apr 2006 07:13:07 -0700 (PDT)

Guys, it is perfectly legal to have ports that are not
behave-compliants.

It just means you are reserving these ports for applications that
have a short-lived timer. You can't use them for behave media.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Ariel Shaqed (Scolnicov)
> Sent: Tuesday, April 25, 2006 01:29
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: Re: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution 
> comments ondraft-ietf-behave-nat-udp-05)
> 
> 
> On Monday 24 April 2006 10:53, Magnus Westerlund wrote:
> > Pyda Srisuresh wrote:
> > > [suresh] I agree, makinng the timers long can be problematic to a 
> > > number of NAT vendors, especially those that make low-end NAT 
> > > devices with limited resources. NAT vendors fine tune 
> these timeouts 
> > > to suit their customer environmets. If IETF mandates the 
> timeouts to 
> > > be long, the vendors could run into support problems they had not 
> > > not anticipated as NATs run out of resources quickly. 
> IETF will not 
> > > be there to help them with the support issues.
> > >
> > > My vote is to keep the timer at 1 minute. I believe, 
> setting this to 
> > > more than 2 minutes  could potentially invite unknown support 
> > > issues. Many vendor might in turn choose not to adapt the 
> madanted 
> > > timeouts. My 2c.
> >
> > Okay, but what is worst, unknown support issues or practical issues 
> > such that wireless devices will drain their batteries much faster? 
> > Unless you can point to actual practical problems I suggest 
> we raise 
> > it at least to two minutes. I would have liked 5 min but do 
> understand 
> > that goes beyond the commonly used 3 minutes which I agree have to 
> > large potential to create issues with deployed NATs.
> 
> Some bad things:
> 
> 1. Not only the 1st NAT on the path is affected.  If an 
> application sends 
> keepalives every 2 minutes it will not work with firewalls 
> anywhere along 
> its path that keep a smaller timeout for UDP connections and 
> also inspect 
> the protocol.  It is probably not very practical to hold a 
> UDP connection 
> (i.e. its current state) open on a firewall for 5 minutes of 
> inactivity.
> 
> Note that even 0 bits of stored state can make the 
> difference: Consider a 
> firewall dropping all UDP connections in one direction.
> 
> It make sense to specify minimal timeouts, just not for all UDP ports.
> 
> 
> 2. The above, when the firewall is NATting its internal domain.
> 
> 3. Some UDP connections are extremely short-lived.  An 
> example with port> 
> 1024 is RADIUS, which (in some modes) performs many short 
> exchanges.  The 
> requirement limits the number of concurrent sessions 
> possible.  There are 
> <65000 ports available for NAT.  If we reserve ports for 300 
> seconds this 
> yields a sustained rate of <216 connections per second to a 
> given server.
> 
> It is acceptable for a residential NAT, probably not for #2 above.
> 
> > To me this is a discussion on finding the point where we 
> break so few 
> > bad implementations, while still representing an actual 
> functionality 
> > gain, thus creating a situation where deploying behave 
> compliant NATs 
> > is an advantage and do happens.
> >
> > I do hope that we can raise the bar a bit and not simply take the 
> > smallest common denominator. We are after all doing this on 
> a number 
> > of other points in these requirements.
> 
> The issue here is not (just) of poor existing implementations.
> 
> -- 
> Ariel Scolnicov. _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

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

I meant "short timers"....  Sorry for the confusion.

> Audet, Francois [SC100:3055:EXCH]
> Sent: Thursday, April 27, 2006 09:17
> To: Ariel Shaqed (Scolnicov); ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: RE: Req-5 (Was:: Re: [Ietf-behave] RE: AD evalution 
> 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.
> 
> > From: Ariel Shaqed (Scolnicov) [mailto:ascolnic@xxxxxxxxxxxxxx]
> > Sent: Wednesday, April 26, 2006 23:20
> > Cc: Pyda Srisuresh; Audet, Francois [SC100:3055:EXCH]; Magnus 
> > Westerlund
> > 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.
> > 
> > > >
> > > > > 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
> > > > > comments on draft-ietf-behave-nat-udp-05)
> > 
> > [...snipped...]
> > 
> > --
> > Ariel Scolnicov.
> > 
> > 
> _______________________________________________
> Ietf-behave mailing list