Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC

[Fred Baker <[e-mail]>]

While the exact timing is open to opinions, I would suspect the  
original mention derives from a combination of two things.

(1) When TCP was originally under development, in the 1970's, there  
was a sense that a datagram could float around for several minutes,  
which is why the TCP sequence space is as large as it is and why  
timers are what they are.

(2) KC Claffy's dissertation, published in part in SIGCOMM 1993, found  
that TCP sessions could stop sending for several seconds and then  
restart, such as due to an application running off to a back-end  
database or launching a process. She defined a microflow as having  
ended when no datagram in the microflow had been seen for 300 seconds.  
I pushed her to try a number of intervals, including 1, 2, 4, 8  
seconds, 15, 30, 60, and 300. She in fact tested something akin to  
that (in her perl scripts, it was a matter of changing a variable and  
re-running the test on the same data), and she found that 8 seconds  
was a big change - the same session could originate a new datagram as  
late as 300 seconds later, but the probability was that if a session  
had not spoken for 8 seconds it was unlikely to speak again. Today,  
iPhoto uploading to Picasa (I have observed) can stall a pipelined TCP  
session for 15 seconds, so the interval is probably longer - for  
safety I would talk about 30-60 seconds.

Why two minutes? Probably safety, coupled with the fact that UDP has  
no counterpart to "RST" that can be interpreted to short-circuit a  
session being ended.

On Apr 24, 2009, at 11:00 AM, Dan Wing wrote:

>
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of
>> [e-mail]
>> Sent: Friday, April 24, 2009 4:46 AM
>> To: [e-mail]; [e-mail]
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: RE: draft-ietf-v6ops-cpe-simple-security-04 WGLC
>>
>> Hi,
>>
>> I believe this document is of operational utility.
>>
>> Few comments/questions:
>> - 3.2.2. describes, as per RFC4787, that UDP mappings MUST
>> NOT expire in less than two minutes. As I don't know the
>> backgrounds of this decision,
>
> It is probably from REQ-5 of
> http://tools.ietf.org/html/rfc4787#section-4.3.
>
>> I wonder why the minimum time
>> could not be longer for IPv6? The longer the time the less
>> need to activate radio for keep-alive sending (on either side
>> of the firewall btw - consider a case where CPE has wireless
>> WAN). In CGN case short timeout is understandable due need to
>> save public ports, but that probably is not an issue in
>> simple IPv6 firewall. So why e.g. not two hours as for TCP?
>
> Two hours seems a long time to leave your door open.
>
> A longer timeout could be negotiated between the the host and its  
> CPE router
> using whatever protocol exists and becomes a defacto standard on  
> IPv6 networks
> (e.g., draft-woodyatt-ald, UPnP IGD version 2).
>
> -d
>
>> - 3.2.5. Just to check that DSMIP6 is considered as one of
>> these other tunneling protocols mentioned in R22? How about
>> MIP6 route optimization, will that work through a device
>> implementing this specification?
>> - 3.4 says it remains to be seen if UPnP:IGD is to be
>> extended for IPv6. I would rather say that IPv6 is being
>> added to UPnP:IDG2. See:
>> "http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d100320
>> 09.pdf  "UPnP Gateway committee: IGD:2 improvements over IGD:1"
>>
>> Best regards,
>>
>> 	Teemu
>>
>>
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of ext Fred Baker
>>> Sent: 15 April, 2009 18:27
>>> To: IPv6 Operations
>>> Cc: [e-mail]; [e-mail]
>>> Subject: draft-ietf-v6ops-cpe-simple-security-04 WGLC
>>>
>>> This is to initiate a two week working group last call of
>>> draft-ietf- v6ops-cpe-simple-security-04. Please read it now.
>>> If you find nits (spelling errors, minor suggested wording
>>> changes, etc), comment to the authors; if you find greater
>>> issues, such as disagreeing with a statement or finding
>>> additional issues that need to be addressed, please post your
>>> comments to the list.
>>>
>>> We are looking specifically for comments on the importance of
>>> the document as well as its content. If you have read the
>>> document and believe it to be of operational utility, that is
>>> also an important comment to make.
>>>
>>>
>