Subject: Re: [Tsvwg] Follow-up : Effects of port randomization with TCP TIME-WAIT state

From: Joe Touch <[email-masked]>
Date: Tue, 02 Sep 2008 14:52:54 -0700

Hi, all,

Sorry for the late contribution to the thread, but here is some input on
the issue...

> Hi,
>    A presentation was made in Dublin (albeit short due to lack of time)
> about the following draft  :
> 
> http://www.ietf.org/internet-drafts/draft-ananth-tsvwg-timewait-00.txt
> 
...
> 
> Option #1 
> =========
> Merge the ideas listed by this draft into the existing port
> randomization draft. 

I agree this is the best option. I should be sufficient to submit a
section of text to Fernando. That text should include more complete
references, notably to the time-wait assassination hazard.

> - The port randomization draft is incomplete if it doesn't not address
> and offer solutions  to the problems seen due to the TCB lingering in
> TIME-WAIT state.
> 
> - FWIW, the port randomization draft DOES talk about TCP and it DOES
> mention about port-reuse property and touches upon the TIME-WAIT state,
> but doesn't offer a "fool proof" solution which addresses this issue.

Your bit-array solution is referred to in RFC1948; it's basically having
the client keep a TIME_WAIT state (with variations on timers).

The array referred to in 3.2 of Fernando's draft doesn't seem required
to me; even if the port is reserved, it should be OK to use it as the
source port of a new connection anyway. I don't see a reason for it.

I'll send a separate note on this issue as it applies to Fernando's draft.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 02 Sep 2008 20:18:52 -0300

>references, notably to the time-wait assassination hazard.

Version -02 of the draft already references RFC 1337. (see Section 2.3)

>the client keep a TIME_WAIT state (with variations on timers).

I have not yet included a description of the two algorithms described 
in Anantha's draft, but was willing to do so. I basically committed 
all the changes I had in the pipeline, and resubmitted the draft, as 
it had expired.

I had asked James Polk if it was okay to include a description of the 
algorithms describes in Polk and Anantha's draft, and he had agreed, 
but wanted to double-check this with Anantha, as he had not responded.

FWIW, I would have liked to describe what Cisco was doing wrt port 
randomziation, and IIRC I had even asked this on the tcpm 
mailing-list.... but got no response.

Kind regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Sep 2008 16:50:21 -0700

Hi, Fernando and Ananth,

> Version -02 of the draft already references RFC 1337. (see Section 2.3)

Yours did; I was referring to Ananth's.

> I have not yet included a description of the two algorithms described in
> Anantha's draft, but was willing to do so. I basically committed all the
> changes I had in the pipeline, and resubmitted the draft, as it had
> expired.

I'm not sure about whether the algorithms are important, or just the
overall issue. The point is that the cost of stepping on a TIME-WAIT is
high, and *may* be useful to avoid that where efficiently possible.
I.e., just as the doc doesn't recommend a randomization algorithm, it
might not need to recommend a TIME-WAIT avoidance mechanism in detail
either. Both are, AFAICT, implementation optimizations.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 3 Sep 2008 08:52:43 -0700

> Hash: SHA1
> 
> Hi, all,
> 
> Sorry for the late contribution to the thread, but here is 
> some input on the issue...

Not an issue, comments welcome, since there was some initial flurry of
email exchanges when I posted this draft, after that it has been very
quiet.

> 
> > Hi,
> >    A presentation was made in Dublin (albeit short due to lack of 
> > time) about the following draft  :
> > 
> > 
> I agree this is the best option. I should be sufficient to 
> submit a section of text to Fernando. That text should 
> include more complete references, notably to the time-wait 
> assassination hazard.

Ok, I am inclined to go with this route as well.

> > mention about port-reuse property and touches upon the TIME-WAIT 
> > state, but doesn't offer a "fool proof" solution which 
> addresses this issue.
> 
> Your bit-array solution is referred to in RFC1948; it's 
> basically having the client keep a TIME_WAIT state (with 
> variations on timers).

Well, per my reading of RFC 1948, it focusses on ISN randomization and
this is as much far it goes when talking about TIME-WAIT state :

"The obvious way to do this is to maintain state for dead connections,
   and the easiest way to do that is to change the TCP state transition
   diagram so that both ends of all connections go to TIMEWAIT state.
   That would work, but it's inelegant and consumes storage space.
   Instead, we use the current 4 microsecond timer M and set

           ISN = M + F(localhost, localport, remotehost, remoteport).

   It is vital that F not be computable from the outside, or an attacker
   could still guess at sequence numbers from the initial sequence
   number used for some other connection.  We therefore suggest that F"

Whereas the current draft talks about maintaining minimal state up to 2
MSL to ensure that you don't pick up the same local port. 

-Anantha
> 
> The array referred to in 3.2 of Fernando's draft doesn't seem 
> required to me; even if the port is reserved, it should be OK 
> to use it as the source port of a new connection anyway. I 
> don't see a reason for it.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAki9s+UACgkQE5f5cImnZrt3VACgxYHB3X3xrJEQrkMwwXKBxHtq
> 5fEAoIH47ZHaAX1affPk6spQeO3fzS0g
> =5g2V
> -----END PGP SIGNATURE-----
>

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 3 Sep 2008 09:02:31 -0700

Fernando, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Fernando Gont
> Sent: Tuesday, September 02, 2008 4:19 PM
> To: Joe Touch; Anantha Ramaiah (ananth)
> Cc: [email-masked]; James Polk (jmpolk); 
> [email-masked]
> Subject: Re: [Tsvwg] Follow-up : Effects of port 
> randomization with TCP TIME-WAIT state
> 
> > > - The port randomization draft is incomplete if it doesn't not 
> > > address and offer solutions  to the problems seen due to the TCB 
> > > lingering in TIME-WAIT state.
> > >
> >Your bit-array solution is referred to in RFC1948; it's basically 
> >having the client keep a TIME_WAIT state (with variations on timers).
> 
> I have not yet included a description of the two algorithms 
> described in Anantha's draft, but was willing to do so. I 
> basically committed all the changes I had in the pipeline, 
> and resubmitted the draft, as it had expired.
> 
> I had asked James Polk if it was okay to include a 
> description of the algorithms describes in Polk and Anantha's 

Correction : It is "Patrick and Anantha's draft". James Polk was kind
enough to review the initial version of the draft.. 

> draft, and he had agreed, but wanted to double-check this 
> with Anantha, as he had not responded.

Sorry, I might have missed some emails here. [did check my junk folder
as well, no signs of any such email]

> 
> FWIW, I would have liked to describe what Cisco was doing wrt 
> port randomziation, and IIRC I had even asked this on the 
> tcpm mailing-list.... but got no response.

Well, the only queston which I remember you raised was : "does this
scheme which is presented in the draft has any IPR ?', for which Patrick
(co-author) already responded saying : "No".

-Anantha
> 
> Kind regards,
> 
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked] PGP 
> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Sep 2008 09:05:26 -0700

Hi, Ananth,

Anantha Ramaiah (ananth) wrote:
...
> Ok, I am inclined to go with this route as well.

AFAICT, there are two things in your doc:

1. raising the TIME-WAIT state issue, which Fernando's draft already did

2. providing implementation advice on how to address it

I think #1 was already sufficiently covered in Fernando's draft, upon
detailed review.

I think #2 is fine advice, and interesting from an implementation
viewpoint, but out of scope for an RFC.

> MSL to ensure that you don't pick up the same local port. 

AFAICT, your draft talks about ways to efficiently approximate the
single line above: "so that both ends of all connections go to TIMEWAIT
state."

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 3 Sep 2008 09:08:22 -0700

Joe,
 
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Tuesday, September 02, 2008 4:50 PM
> To: Fernando Gont
> Cc: Anantha Ramaiah (ananth); [email-masked]; 
> James Polk (jmpolk); [email-masked]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, Fernando and Ananth,
> 
> Fernando Gont wrote:
> submit a 

Yes, it makes sense. I am also planning to put a reference to yours (and
Ted's) paper on busy servers and time-wait issue, since I think this is
would be a very useful reference.

> >> > - FWIW, the port randomization draft DOES talk about TCP and it 
> >> > DOES mention about port-reuse property and touches upon the 
> >> > TIME-WAIT state, but doesn't offer a "fool proof" 
> solution which addresses this issue.
> >>
> described 
> I'm not sure about whether the algorithms are important, or 
> just the overall issue. The point is that the cost of 
> stepping on a TIME-WAIT is high, and *may* be useful to avoid 
> that where efficiently possible.
> I.e., just as the doc doesn't recommend a randomization 
> algorithm, it might not need to recommend a TIME-WAIT 
> avoidance mechanism in detail either. Both are, AFAICT, 
> implementation optimizations.

Agree, but port randomization draft does list the algorithms (discusses
pros and cons of each algorithm), doesn't recommend it in the recent
version. So, IMO, it is not bad idea to document the problems which we
have faced and the solutions which we have used to overcome them. Again
this shouldn't be treated as a recommendation. 

-Anantha
> iEYEARECAAYFAki90T0ACgkQE5f5cImnZrttXwCgi+CfjaMMZBFR5W2G0OOWYW+A
> 0bAAnjntmIHzv+BXILtcLTjfoajO9PNs
> =cSvJ

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Sep 2008 10:24:05 -0700

Ananth,

>> this shouldn't be treated as a recommendation. 

I think there's a difference between randomization algorithms and
implementations of TIME-WAITs. The former affects the way in which the
ports are reused, and the pattern is seen externally; the latter is an
internal issue. I don't think internal implementation issues are
relevant in an RFC.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 3 Sep 2008 10:52:12 -0700

> >> Agree, but port randomization draft does list the algorithms 
> >> (discusses pros and cons of each algorithm), doesn't 
> recommend it in 
> >> the recent version. So, IMO, it is not bad idea to document the 
> >> problems which we have faced and the solutions which we 
> have used to 
> >> overcome them. Again this shouldn't be treated as a recommendation.
> 
> I think there's a difference between randomization algorithms 
> and implementations of TIME-WAITs. The former affects the way 
> in which the ports are reused, and the pattern is seen 

Actually, this depends on how one tries to see it. Firstly, we are not
talking about implementing a TIME-WAIT state, all we are saying is :
while doing port randomization, if we don't pay attention to the
TIME-WAIT issue, then you will end up into problems. So, all the draft
is trying to emphasize is : to how to addres this side effect which
becomes more prevalent when you do port randomization and depicts ways
to address the same. This is not something totally orthogonal, instead
this is well within the spirits of the port random draft. It tries to
document a field issue wherein we departed from doing a sequential
algorithm to a random algorithm a couple of years back and the issues
which we faced and how we went about circumventing those. 

Well, taking a few steps backward. Port randomization is a useful thing
and one could have approached this problem in the following ways :

#1 explain why port randomization is useful and leave the algorithms up
to the implementations. Don't even mention it.

#2 explain a handful of algorithms to illustarte PR.

#3 also talk about the TIME-WAIT issue since it is important as far as
TCP is concerned. SCTP and other protocols don't have the TIME-WAIT,
FWIW.

#4 elaborate TIME-WAIT issue w.r.t PM (since it is important same
rationale as #3) and mention a few algorithms for the same.

Fernando's draft does #1 to #3 above, but our draft focusses on #4
above. 

I am really confused at this point as why #4 comes across as something
"internal" and the rest as "external". The effects of TIME-WAIT are
external, IMO. Lets assume you have a point, but it seems to be very
thin line to me. The way I read the PM draft is it mentions about
something and draws the line, here we are trying to extend it a bit
further. Hmm.. It boils down to where you want to draw the line, beats
me!

Anyways, we feel that this would be a good value addition to the PM
draft, but would like to hear the consensus of the WG group, more
importantly does the WG feel that it is an important issue that is worth
documenting?

-Anantha

> externally; the latter is an internal issue. I don't think 
> internal implementation issues are relevant in an RFC.
> 
> Joe
> iEYEARECAAYFAki+yDUACgkQE5f5cImnZrv2PQCg+05FF3JXaCPssumUkd3qibfG
> pzoAoPHyIot+wPZzeFPkB2ri6dFjQz6C
> =xRP9

---

From: Fernando Gont <[email-masked]>
Date: Wed, 03 Sep 2008 15:43:27 -0300

>enough to review the initial version of the draft..

Yep, sorry.

>as well, no signs of any such email]

Will forward it asap.

>(co-author) already responded saying : "No".

I said that I would be willing to document any approach that Cisco 
has implemented, and asked if there was an IPR on any of the 
algorithms because, if there was, then it would be counter-productive 
to include IPR-ed material in the draft (it scares people, and they 
end up thinking that the IPR covers the whole document).

I had wanted to do document whatever Cisco was doing on the subject, 
but I don't have access to TCP implementation of IOS, and I don't 
have any Cisco box to try to infer their port selection algorithm myself.

I recall you had mentioned on TCPM that Cisco did something similar 
to what is described in our draft. But that's it, and wasn't enough 
to provide any explanation.

Does Cisco implement both of the algorithms described in your draft? 
One of them in IOS, and the other in....?
Could you provide information about the ephemeral port range used in 
Cisco products?

if you agree, I can include a description of those two algorithms, 
and include a reference stating "these algorithms were first 
described in [Anantha and Patrick's]".

Thanks!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 03 Sep 2008 15:54:00 -0300

>internal issue. I don't think internal implementation issues are

Agreed. In particular, what is described in Anantha and Patrick's 
draft is not a real implementation of the TIME_WAIT state for a 
connection-id on the client side, but is raher the result of such 
implementation after applying the constraints that are found in real systems.

Anantha and Patrick's draft propose not to reuse a *port* if it has 
been last used in less than 2*MSL. But that's more of a stricter 
requirement than really needed, as it's the *connection-id* that 
should be put in the TIME-WAIT state, and not jsut the port. (the sme 
port number could be reused if it would result in a conenction-id 
that is not in the TIME-WAIT state).

Thanks!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 03 Sep 2008 15:56:33 -0300

>Fernando's draft does #1 to #3 above, but our draft focusses on #4

I'm not sure why you think so.  Our port randomization draft does #1 
through #4. Now I have put the discussion of collision of 
connection-id's in a separate section. But most (if not all) of the 
text was already there.

>importantly does the WG feel that it is an important issue that is worth

The issue is very simple: when there are collisions of the 
connection-id in the remote peer, what happens is what RFC 1337 says. 
The only new thing with port randomization is that collisions of 
connection-id's may happen more frequently than before, and therefore 
you may face the problems described in RFC 1337 in scenarios in which 
you didn't use to face them.

However, if algorithm #3 is in place, the situation is exactly the 
same as with the traditional BSD ephemeral port selection algorithm. 
And with algorithm #4 in place, the situation is even *better* (and 
you don't need special magic to handle the issue of collision-id's).

Thanks!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 03 Sep 2008 15:59:34 -0300

>viewpoint, but out of scope for an RFC.

Agreed. waht I would like to know is whether Cisco does anything 
different for the *randomization* of port numbers. If they do, I'd be 
glad to document their approach. Regarding the "both end-points end 
up in the TIME-WAIT state", I agree with Joe. What the implementation 
approach is to do this is out of the scope of the RFC.

Thanks!

Kind regards,