Re: [Int-area] Some comments for 4rd

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of [e-mail]
> Sent: Sunday, April 17, 2011 9:28 PM
> To: [e-mail]; [e-mail]
> Subject: Re: [Int-area] Some comments for 4rd
> 
> Hi Tina
> Thank you for your comments.
> 
> >5.       In section 5 of applicability draft
> >     "Shared address issues [I-D.ietf-intarea-shared-addressing-
> issues] describes a method for
> >  the random selection of TCP Sequence Number, that reduces the
> ability of attacker to correctly guess the 5-ruple."
> 
> >   Random selection of TCP Sequence Number is to prevent the attacker
> from guessing the next TCP SN, not the 5-tuple.
> 
> You are right. I will change it in the next version of draft.

I noticed the existing text in
http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05#se
ction-5 says the client goes into TIME_WAIT ("It is important to realize
that the TCP design makes it undesirable for clients to re-use ports while
they remain in the TIME-WAIT state (typically 4 minutes after the connection
has concluded).") -- however, that depends on the client doing the active
close.  I see that http://tools.ietf.org/html/rfc6056#section-2.3 discusses
what happens when the server does the active close:  the client doesn't go
into TIME_WAIT.  The recommendation in
draft-ietf-intarea-shared-addressing-issues appears to re-enforce the
suggestion in the last sentence of
http://tools.ietf.org/html/rfc6056#section-2.3, which says:

   A simple but inefficient approach to minimize the rate of collisions
   of instance-ids would be, e.g., in the case of TCP, for both
   endpoints of a TCP connection to keep state about recent connections
   (e.g., have both endpoints end up in the TIME-WAIT state).

perhaps you could cite RFC6056 and reduce the discussion in Section 5?

-d