Re: [shara] port randomization (draft-ymbk-aplusp-03)

["Dan Wing" <[e-mail]>]

Following up on my own post: 

> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 
> > Sent: Monday, March 16, 2009 6:08 PM
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: [shara] port randomization (draft-ymbk-aplusp-03)
> > 
> > 
> >   >additional work is necessary to *release*
> >   >ports, so that the CPE can get a fresh port (or fresh block
> >   >of ports).
> > 
> > Isn't this the task of the protocol between the PRR and CPE? 
> 
> Yes.
> 
> > Wouldn't a lease time associated with each allocated port or 
> > port range be enough?
> 
> Somewhat; the CPE might want to get a new port more aggressively
> for whatever reason.
> 
> Let's pretend we had a SHARA solution in place in 2005, and 
> everybody agreed in 2005 that a 1 hour lease made sense.  The
> SP equipment was configured to provide a 1 hour lease of a
> bunch of random ports.  Then Kaminsky DNS attack surfaces in 2008, 
> 3 years later.  Due to that attack, CPE want to get a fresh, 
> random UDP port for every DNS query.  Does the existing DHCP 
> lease mechanism support a CPE wanting/needing to do that?  It
> is my understanding that it does not;

That is, for some ports (read: applications), aggressively
short port leases may be desirable while for other ports it 
may be desirable to have longer leases.  Having the client
request a short lease duration for any port might work, but
seems chatty because the client will have to refresh the
lease even for ports that are actively sending/receiving
traffic.  The PRR can already tell which ports are actively
sending/receiving traffic (because it is forwarding that
traffic).

Perhaps this is getting too much into the details of the
design of the protocol between the CPE and the PRR.

-d



> if my understanding is
> correct, I believe it is in our best interest to be have a 
> protocol that does support the CPE asking for whatever port
> forwarding it wants/needs.  Putting the power into the 
> customer's hands rather than the SP's hands is the primary 
> goal of SHARA, afterall.
> 
> -d
> 
> 
> > - gabor
> > 
> >   >-----Original Message-----
> >   >From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of
> >   >ext Dan Wing
> >   >Sent: Monday, March 16, 2009 5:33 PM
> >   >To: 'Jan Zorz @ go6.si'
> >   >Cc: [e-mail]
> >   >Subject: Re: [shara] port randomization (draft-ymbk-aplusp-03)
> >   >
> >   >> 	And, the CPE does not necessarily need to 
> request each port;
> >   >it
> >   >> 	could ask for ~5 or ~10 ports and then utilize 
> them as it
> >   >needs,
> >   >> 	and then get another batch of ~10 ports.  It 
> comes down to
> >   >> 	the design decisions for the protocol between 
> the CPE and the
> >   >> 	PRR so that it is possible to utilize the 
> entire 64K port
> >   >> 	range.
> >   >>
> >   >>
> >   >> Yes, this is possible within described mechanism in A+P
> >   >> proposal, as minimum port range is not limited, so you can
> >   >> define 10 ports as a range, but preferably a range, that can
> >   >> be described with a bitmask.
> >   >
> >   >I agree that allocating ports is discussed in Section 4.4
> >   >of http://tools.ietf.org/html/draft-ymbk-aplusp-03; however,
> >   >my point is that additional work is necessary to *release*
> >   >ports, so that the CPE can get a fresh port (or fresh block
> >   >of ports).
> >   >
> >   >-d
> >   >
> >   >_______________________________________________
> >   >shara mailing list
> >   >[e-mail]
> >   >https://www.ietf.org/mailman/listinfo/shara