Subject: [Tsvwg] Moving forward the port randomization draft?

From: Fernando Gont <[email-masked]>
Date: Sun, 09 Nov 2008 20:33:08 -0300

Hello, folks,

Our port randomization draft has been pretty stable over the last few 
revisions. We still have to address some detailed comments sent by 
Mark Allman, but we think that once Mark's comments are addressed, 
our draft would be ready for WGLC.

We therefore would appreciate any feedback you have on the current 
version of the draft 
(http://tools.ietf.org/id/draft-ietf-tsvwg-port-randomization-02.txt), 
so that in the event you think some changes are necessary, we could 
address your comments in the next revision of the draft, and maybe 
ask to start a WGLC of the document once that revision is published.

Thanks!

Kind regards,

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

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 9 Nov 2008 20:11:20 -0800

Fernando,
   The following draft was written which basically says that with port
randomization and the algorithms which is recommended (or suggested) in
the port randomization draft, we can run into an issue with port
collisions under certain cases.

http://www.ietf.org/internet-drafts/draft-ananth-tsvwg-timewait-00.txt

We have received some comments (from you and other WG members) public
and private, have had some email exchanges. Nothing has been concluded
so far on this. My point is since PR draft does list some algorithms, if
there is an issue with those algorithms then it needs to be spelt out. 

FWIW, we are also planning to update our draft with more simulation
results etc., (to prove the case in point) and will roll out a new
version when time permits. 

-Anantha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Fernando Gont
> Sent: Sunday, November 09, 2008 3:33 PM
> To: [email-masked]
> Subject: [Tsvwg] Moving forward the port randomization draft?
> 
> Hello, folks,
> 
> Our port randomization draft has been pretty stable over the 
> last few revisions. We still have to address some detailed 
> comments sent by Mark Allman, but we think that once Mark's 
> comments are addressed, our draft would be ready for WGLC.
> 
> We therefore would appreciate any feedback you have on the 
> current version of the draft 
> so that in the event you think some changes are necessary, we 
> could address your comments in the next revision of the 
> draft, and maybe ask to start a WGLC of the document once 
> that revision is published.
> 
> Thanks!
> 
> Kind regards,
> 
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked] PGP 
> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Nov 2008 02:21:31 -0300

>http://www.ietf.org/internet-drafts/draft-ananth-tsvwg-timewait-00.txt

I don't believe this document should stop the port randomization 
draft from moving forward.

FWIW, the port randomization draft has been a wg item for quite some 
time now. And I don't think your "time wait" ID has so far received 
much support.

We had a very lengthy discussion off-list, in which the high order 
bit of my arguments basically were:

* Did you have this problem before implementing port randomization? 
(I expect "No").

* What's the reason for which you implemented port randomization? (I 
expect "to obfuscate the source port, so that it's harder for 
off-path attacker to attack my TCP connections").

* Is there any technical reason for which you adopted the port 
randomization algorithm you adopted to achieve the goal you wanted to achieve?

* Couldn't you have adopted some other algorithm that would have 
avoided the problem altogether?

And finally,

* Do you implement the 4.4BSD SEQ# hack and a TCP timestamps 
selection algorithm such as that described in 
draft-gont-tcpm-tcp-timestamps? If not, why not? And why would you 
add extra machinery when in virtually all cases this would have 
solved your problem?

P.S.: FWIW, I don't think any simulation you provide will add much to 
this discussion: of course you'll be able to find scenarios in which 
some of the described algorithms may experience problems. You simply 
picked the wrong algorithm for your scenario. (Also, please answer 
the last question in the list).

Thanks!

Kind regards,

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 10 Nov 2008 07:34:56 -0800

Answers inline : 

> From: Fernando Gont [mailto:[email-masked]] 
> Sent: Sunday, November 09, 2008 9:22 PM
> To: Anantha Ramaiah (ananth); [email-masked]
> Cc: Mark Allman
> Subject: RE: [Tsvwg] Moving forward the port randomization draft?
> 
> I don't believe this document should stop the port 
> randomization draft from moving forward.
> 
> FWIW, the port randomization draft has been a wg item for 
> quite some time now. And I don't think your "time wait" ID 
> has so far received much support.
> 
> We had a very lengthy discussion off-list, in which the high 
> order bit of my arguments basically were:
> 

With sequential allocation of ports the collisions were not seen, since
the wraparound rate was very long. (atleast in our case)

> 
> * What's the reason for which you implemented port 
> randomization? (I expect "to obfuscate the source port, so 
> that it's harder for off-path attacker to attack my TCP connections").

Yes. It needs to be noted that the algorithm used to choose the src port
is similar to choosing the ISN ( typically a high quality PRNG) in our
case.

> 
> * Is there any technical reason for which you adopted the 
> port randomization algorithm you adopted to achieve the goal 
> you wanted to achieve?

Yes. Something similar to algorithm #2 is the one which we want to use
due to its good randomness property. Algorithms #3 and #4 suffers in
randomness quality when compared to algorithm #2. [Question : Have you
tried evaluating your random numbers produced using algorithms #3 and #4
?]

> 
> * Couldn't you have adopted some other algorithm that would 
> have avoided the problem altogether?

Well, lets assume we use some form of obfuscation, again when we try to
pass the randomness test, it does not come across as high quality. "if
the requirement is having good PRNG, and the PRNG is stateless, then you
may run into the scenarios described in our draft". The sure-shot way of
avoiding collisions is to maintain state about the recently passively
closed connections and NOT to re-use the same src-port until the
TIME-WAIT time. This is the message which our draft is trying to convey
based on the scenarios which we observed on the field. 

> draft-gont-tcpm-tcp-timestamps? If not, why not? And why 

Draft-gont-timestamps just came out, our TIME-WAIT state stuff is
running in the field for almost 2 years. 

We DID discuss this 4.4 BSD hack. Now it assumes the following. Either
:-

- you use timestamp option [ this cannot be guaranteed always]
- you are assuming that the server is using the BSD 4.4 hack of honoring
a connection request by assassinating the TIME-WAIT state if the initial
sequence number happens to < largest seq# seen on the TIME-WAIT'ing
connection. Pl note that it is a MAY condition by RFC 1122 and you
cannot assume that all implementations adhere to it. Also most
implementations fail to implement the fallback clause recommended by
RFC, thus leading to TIME-WAIT assassination. Anyways it would be
interesting to hear more thoughts about this BSD hack from a wider
audience!

> would you add extra machinery when in virtually all cases 
> this would have solved your problem?
> 
> P.S.: FWIW, I don't think any simulation you provide will add 
> much to this discussion: of course you'll be able to find 
> scenarios in which some of the described algorithms may 
> experience problems. 

We already found it 2 years ago!

> You simply picked the wrong algorithm 

Algorithm #2 is what we picked since it offers the best PRNG quality
among the 4 listed. 

> for your scenario. (Also, please answer the last question in 
> the list).

I did.

Thanks,
-Anantha

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Nov 2008 14:24:00 -0300

At 12:34 p.m. 10/11/2008, Anantha Ramaiah (ananth) wrote:

(He had this conversation already. However, as it was all off-list, I 
just want to state my opinion with respect to this document. But I 
don't think this conversation is getting us anywhere. So unless 
something new is raised, I'll refrain to respond any further e-mails 
in this thread...)

>randomness quality when compared to algorithm #2.

Who cares about randomness? It's obfuscation that matters!

>[Question : Have you

Algorithms #3 and #4 do not produce random numbers. They produce a 
linear function with a random offset. This is explained in our draft.

>pass the randomness test, it does not come across as high quality.

Who cares about this randomness test? Why should you care?

>"if

It's not a sure way. Just issue connections at a rate higher than 
~65K/2*MSL, and you're dead.

>running in the field for almost 2 years.

c'mon Anantha... what'a are you talking about? My timestamps draft 
simply documents what stacks such as Linux have been doing for years. 
I didn't invent anything here. I just documented what had already 
been done. And it is not a competition of "who arrived first". I just 
think there's no enough justification for all the machinery you 
implemented other than.... who knows... satisfying a customer that 
was simply willing to pay for it.

>cannot assume that all implementations adhere to it.

Linux does it. BSDs do it. RFC 1948 is your friend. If you want to 
ignore the advice provided ten years ago, what can I say?

>Algorithm #2 is what we picked since it offers the best PRNG quality

I have already repeated it quite a few times: you should not care 
about randomness. You should care about obfuscation. "port 
randomization" is a misnomer.

Kind regards,

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 10 Nov 2008 10:44:06 -0800

Fernando,
    Pl see inline. I think you have made your point and so as me, but
wanted to close on some points :

> Sent: Monday, November 10, 2008 9:24 AM
> Subject: Anantha's time-wait id (was: Re: [Tsvwg] Moving 
> forward the port randomization draft?)
> 
> (He had this conversation already. However, as it was all 
> off-list, I just want to state my opinion with respect to 
> this document. But I don't think this conversation is getting 
> us anywhere. So unless something new is raised, I'll refrain 
> to respond any further e-mails in this thread...)

Ditto.

> > > randomization algorithm you adopted to achieve the goal 
> you wanted 
> > > to achieve?
> >

Well, "who cares" is a very subjective matter. Some implementations do
care. If you are saying that IETF shouldn't really care about
implementation stuff, that everyone understands. The point here is that
your draft *does* advocate some algorithms under the hood of "port
randomization" and simply stops at that without elaborating on the
TIME-WAIT issues. So, it seems to me as the problem of incorrectly
drawing the line somewhere?

> 
> 
> >[Question : Have you
> >tried evaluating your random numbers produced using 
> algorithms #3 and 
> >#4 ?]
> 
> Algorithms #3 and #4 do not produce random numbers. They 
> produce a linear function with a random offset. This is 
> explained in our draft.
> 
> 
> 

We do care :-)

> ~65K/2*MSL, and you're dead.

Correct. What is the point here?

> was simply willing to pay for it.

Justfication? You are sounding very funny here... It is a problem which
we observed and fixed it. Agreed, it may not be a generic problem, but
we just wanted to share the information. Your draft suggests "port
randomization", now you seem to say "who cares about port randomization,
all we care is obfuscation"?  I think it is better to be consistent. To
me, it is the same as the way we pick ISN's one is 32 bit quantity and
the other (ports) are 16 bit. (both are random numbers)

> ignore the advice provided ten years ago, what can I say?

I know, but we cannot rely on the fact that the peer does it (the one
which is in TIME-WAIT), and also the ISN generation logic cannot be
stateful to always generate a sequence # > the one which was used by the
previous connection. 

> randomization" is a misnomer.

Well, your document calls it "port randomization" ;-)

-Anantha.

---

From: Mark Allman <[email-masked]>
Date: Mon, 10 Nov 2008 13:57:20 -0500

> Justfication? You are sounding very funny here... It is a problem
> which we observed and fixed it. Agreed, it may not be a generic
> problem, but we just wanted to share the information. Your draft
> suggests "port randomization", now you seem to say "who cares about
> port randomization, all we care is obfuscation"?  

Let's be fair here:

  + Fernando's draft is mis-named.  Maybe we could get it changed.

  + On the flip side, if one actually reads Fernando's draft it is clear
    that not all the algorithms depend on randomness and IMO is pretty
    clear in the text that obfuscation is the real point.

allman

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Nov 2008 11:05:55 -0800

> http://www.ietf.org/internet-drafts/draft-ananth-tsvwg-timewait-00.txt

I don't see this as related to Fernando's port-randomization doc;
port-randomization focuses on the issue of blind attacks, and deals with
collisions as a secondary issue.

Anantha's doc focuses on collisions - an issue which is already very
well known.

IMO, this document has two parts:

	1) highlighting the TIME-WAIT issue

	2) describing algorithms for dealing with TIME-WAIT

#1 is sufficiently documented in RFC1337 as an issue, and in a paper
(Faber, Touch, Yue, Infocom 1999) as being exacerbated by client-server
interactions. The issue doesn't need to be explained further, and if it
is summarized in a paragraph or so, it should cite this prior work.

As Fernando noted, it's irrelevant why reuse occurs. Your sole point in
this area appears to be a suggestion that randomization algorithms might
reuse port numbers more quickly than sequential algorithms. That's worth
a sentence or two in Fernando's doc at best.

The algorithms in #2 are misleading, and I don't see the point in
documenting implementations that don't implement the current
requirements. They avoid reuse of the source port altogether, whereas it
is the 5-tuple (srcIP, dstIP, srcport, dstport, proto) which needs to
not be reused.

The algorithms, FWIW, are naiive regarding timers; it's sufficient to
put a timestamp (even a very coarse one) in the location and check the
timestamp when the port is reused, rather than "run timers" as processes.

Overall, I don't see the utility of this document at all. The primary
outcome appears to be that Fernando should note that randomization
*might( cause port collisions earlier than sequential port reuse.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 10 Nov 2008 13:13:45 -0600

>   + Fernando's draft is mis-named.  Maybe we could get it changed.

With my chair hat on -- given Fernando himself wrote that randomness 
isn't the goal, a name change in the doc is a minimum to move it forward.

I will ask that obfuscation itself is (fairly verbosely) defined in 
the newly titled draft, so that even a casual reader understands 
exactly what the authors mean when using the term.

>     clear in the text that obfuscation is the real point.

Mark - do you believe Ananth's TIME-WAIT doc brings up a valid point 
(i.e., something not solved in all cases within the "Port Obfuscation 
" doc?  Or is this chasing too small a corner case? Or is there no 
validity to Ananth's doc in your opinion?

One additional question - does Ananth's doc do harm to the Internet, 
or is in just inconsistent with Fernando's obfuscation doc?

With my chair hat off -- it seems there is a point to Ananth's 
effort, but I want to understand if it is worth addressing in any effort.

James

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 10 Nov 2008 11:33:38 -0800

Joe,
  Pl see inline. 

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Monday, November 10, 2008 11:06 AM
> To: Anantha Ramaiah (ananth)
> Cc: Fernando Gont; [email-masked]
> Subject: Re: [Tsvwg] Moving forward the port randomization draft?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> > randomization and the algorithms which is recommended (or 
> suggested) 
> > in the port randomization draft, we can run into an issue with port 
> I don't see this as related to Fernando's port-randomization 
> doc; port-randomization focuses on the issue of blind 
> attacks, and deals with collisions as a secondary issue.
> 
> Anantha's doc focuses on collisions - an issue which is 
> already very well known.
> 
> #1 is sufficiently documented in RFC1337 as an issue, and in 
> a paper (Faber, Touch, Yue, Infocom 1999) as being 
> exacerbated by client-server interactions. The issue doesn't 
> need to be explained further, and if it is summarized in a 
> paragraph or so, it should cite this prior work.

Yes, we could cite this reference. I did mention earlier ( see when I
posted the draft, the Faber's paper would be added as a reference as
well), pl refer earlier emails!

> 
> As Fernando noted, it's irrelevant why reuse occurs. Your 
> sole point in this area appears to be a suggestion that 
> randomization algorithms might reuse port numbers more 
> quickly than sequential algorithms. That's worth a sentence 
> or two in Fernando's doc at best.

Ok, but I will go beyond that. Since Fernando's document lists some
algorithms to be begin with supposedly offering port randomization. Now
it also briefly talks about port re-use and does mention the word
TIME-WAIT etc., but doesn't bother to elaborate more. Fair enough, but
my point here is that since you already mentioned algorithms (these are
implementation details), why not mention an algorithm which is robust
against this TIME-WAIT issue? Like I said it seems like we are saying
everything, advocating algorithms, but fail to acknowledge an algorithm
that would work for TIME-WAIT issue. 

> 
> The algorithms in #2 are misleading, and I don't see the 
> point in documenting implementations that don't implement the 
> current requirements. They avoid reuse of the source port 
> altogether, whereas it is the 5-tuple (srcIP, dstIP, srcport, 
> dstport, proto) which needs to not be reused.

We have received a few suggestions regarding the algorithms described in
our draft. What you mention above would be addressed in the next
version.

> 
> The algorithms, FWIW, are naiive regarding timers; it's 
> sufficient to put a timestamp (even a very coarse one) in the 
> location and check the timestamp when the port is reused, 
> rather than "run timers" as processes.

Yes, I think this has been brought during some internal reviews as
well.. Next version should have something...

> 
> Overall, I don't see the utility of this document at all. The 
> primary outcome appears to be that Fernando should note that 
> randomization *might( cause port collisions earlier than 
> sequential port reuse.

IMO, also should list solutions that work for this case, not simply
mention it. Or better off remove all references of TIME-WAIT and port
re-use ( make it as a generic non-TCP draft) and leave it at that, then
I am happy with that. Since it does mention TIME-WAIT etc. and also goes
on to list "some" algorithms, I don't any issues listing other
algorithms which would work as well and would address the TIME-WAIT
issue.

-Anantha

---

From: Mark Allman <[email-masked]>
Date: Mon, 10 Nov 2008 14:54:56 -0500

James-

> exactly what the authors mean when using the term.

I believe if you read the document you will find that it clearly spells
out that obfuscation to prevent blind attacks is the goal.

> (i.e., something not solved in all cases within the "Port
> Obfuscation " doc?  Or is this chasing too small a corner case? Or
> is there no validity to Ananth's doc in your opinion?

That's a bunch of questions.  Anantha (and his co-authors), Fernando and
I have gone around on this a bunch offlist.  Anantha is going to rev his
I-D and so perhaps a better story on their situation would change my
mind on all this and so I want to explicitly leave that out as a
possibility.  But, since you asked, at this moment I think ...

  + All the algorithms in the Larsen draft can lead to collisions.  Even
    the traditional inc-by-one algorithm can experience collisions.  The
    algorithms are not, however, equally susceptible to collisions.

  + I believe that different applications and situations dictate
    different tolerance to these collisions.

  + Anantha has a particular application / situation that [to the best
    of my understanding] (1) makes a ton of connections between two
    machines using the same service, (2) requires the use of *random*
    ephemeral ports (alg. 2) and (3) has a quite low tolerance for
    collisions.

  + So, for Anantha the problem detailed in his draft is real.  So, it's
    hard to say there is no validity there for him.  That said, while I
    don't discount these requirements **in Anantha's case** it is a
    pretty small box he finds himself in.  

    E.g., I do not doubt that he needs to use algorithm 2, but algorithm
    3 works quite well for the general case, I believe---and would
    largely take care of the third requirement above without any
    additional state.

  + I have crunched data from ICSI and LBNL (I sent around a draft and
    continue to hammer it into better shape) and in the **worst case** I
    can come up with (NATed LBNL connectivity; 240sec TIME-WAIT period)
    I find ~0.3% collision rate for algorithms 1 & 2 and orders of
    magnitude less than that for algorithms 3 & 4.  

    So, in the context of actual network data I do in fact find
    Anantha's case to be a pretty small corner case in the general
    scheme of things.

    (And, let me be clear and say that I understand ICSI and LBNL are
    not representative of every situation on the network.  These just
    happen to be what I have handy to crunch.  However, this data does
    confirm my mental model which suggests that general traffic dynamics
    do not present much of a problem for any of the algorithms sketched
    in the Larsen draft.)

  + I have suggested to Fernando (who I believe is amenable, but will
    correct me if I am wrong) that his document should note that an
    implementation can avoid collisions all together (unless all
    ephemeral ports are in use, of course) by tracking recently closed
    connections on both end hosts.  (And, that's it.  I.e., not how one
    could do this, just that it is possible if one wants more than
    probabilistic protection against collisions.)

    In other words, while I think it is a corner case I don't see
    anything wrong with flagging it for implementers to consider in some
    fashion. 

> or is in just inconsistent with Fernando's obfuscation doc?

IMO, Anantha's draft does not harm the Internet.

IMO, Anantha's draft is not inconsistent with the Larsen draft.

IMO, Anantha's draft does not describe a general problem and therefore
expending IETF cycles to get it into publishable shape and move it
through the process sounds pretty dubious to me.

I hope that helps!

allman

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 10 Nov 2008 14:29:55 -0600

>through the process sounds pretty dubious to me.

My takeaway from this discussion - which is not inconsistent with 
other discussions - is that Ananth needs to justify why this needs to 
be addressed by TSVWG (i.e., more common that folks think, or more 
frequently occuring that folks think or it occurs more often than 
folks think) in order to move this effort forward.

I think this is a pretty common goal (any one of the 3, or 
combinations) for new effort.

Ananth is revving the doc, and let's see how that furthers his cause.

James

---

From: Mark Allman <[email-masked]>
Date: Mon, 10 Nov 2008 16:42:17 -0500

> Ananth is revving the doc, and let's see how that furthers his cause.

I believe that is a fair assessment.

allman

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Nov 2008 16:27:33 -0800

Hi, Anantha,

> well), pl refer earlier emails!

I'm saying something stronger. I don't believe a summary of these other
documents is needed in this document; if a summary is needed, it can be
much briefer (2 sentences: there's a known problem, and see these other
documents for details).

> that would work for TIME-WAIT issue. 

It is worth noting that randomization algorithms may generate collisions
more frequently than serial algorithms. It may be worth noting that
collisions need to be avoided anyway by means outside the algorithm.

I don't think it's worth designing an algorithm that tries to avoid
collisions per se.

> our draft. What you mention above would be addressed in the next

Fair enough. My overall concern is that what's really needed is an
efficient way to check for collisions, and the typical solution would be
a simple hash to a small data structure that's scanned. I.e., a solution
should not generate false positives for every IP address pair and
destination port that would try to reuse a given source port.

...
> mention it. 
> Or better off remove all references of TIME-WAIT and port

TIME-WAIT management is already required, and already an issue even for
sequential port assignment. Randomization might affect some naiive
algorithms for avoiding TIME-WAIT reuse, but overall a good solution to
TIME-WAIT management should be independent of the port assignment
algorithm anyway.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Nov 2008 21:46:14 -0300

At 03:44 p.m. 10/11/2008, Anantha Ramaiah (ananth) wrote:

>implementation stuff, that everyone understands.

What I'm saying is that I really don't understand why you should care 
about randomness rather than about obfuscation.

>The point here is that

For the most part, it describes a number of algorithms, and it 
clearly states that the most trivial ones may lead to collisions. For 
the most part, we document them because some stacks have implemented 
them. But the advice you should read from the draft is that if you do 
care about collisions, you should be doing #3 or #4, rather than 
implementing the trivial obfuscation approach, and then having to add 
extra-machinery to deal with collision issues.

> > Who cares about this randomness test? Why should you care?

Yes, I know you care. Should *we* care? (you're bringing this to the IETF)

>Correct. What is the point here?

That you still avoid only *some* collision scenarios.

>we observed and fixed it.

My take is that it was picking the wrong obfuscation approach that 
introduced the problem.

>Agreed, it may not be a generic problem, but
>all we care is obfuscation"?  I think it is better to be consistent.

As I said, "port randomization" is a misnomer. "randomization" is 
simply *one* approach to obfuscate port numbers.

>To

And this is another reason for which some of your connections were 
failing: the BSD SEQ hack would not work with random ISNs.

>which is in TIME-WAIT),

What's the specific stack that your're referring to? (that does not 
implement the BSD SEQ hack)

>and also the ISN generation logic cannot be

It doesn't need to be stateful. For instance, the RFC 1948 scheme is 
not stateful, and still complies with these requirements.....

>Well, your document calls it "port randomization" ;-)

Yes, shame on me. We used such a misnomer, as that's how the industry 
has always referred to "port obfuscation". We might change the 
document title....

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Nov 2008 22:29:37 -0300

At 04:33 p.m. 10/11/2008, Anantha Ramaiah (ananth) wrote:

>TIME-WAIT etc., but doesn't bother to elaborate more.

The goal of the document is to obfuscate port 
numbers as a mitigation for blind attacks.

>Fair enough, but

We mention time-wait and port collisions simply 
to state the characteristics that an obfuscation approach should probably have.

>algorithms which would work as well and would address the TIME-WAIT

Your *obfuscation* algorithm *is*¨mentioned in 
our draft. What's not mentioned is the TIME-WAIT 
machinery you have implemented, because that's 
simply out of the scope of our doc.

Thanks!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Nov 2008 22:35:22 -0300

>     probabilistic protection against collisions.)

FWIW, yes, I confirm that I will be incorporating text in response to 
your suggestion.

Kind regards,

---

From: Mark Allman <[email-masked]>
Date: Tue, 11 Nov 2008 20:55:14 -0500

Guys-

If we all promise to keep an xterm open and run the following bit of
python in it will you stop?

#!/usr/bin/env python

import random
import time

while True:
    print "Anantha> We have to use algorithm 2."
    time.sleep (random.uniform (60,86400))
    print "Fernando> You're using the wrong algorithm."
    time.sleep (random.uniform (60,86400))

Really... we aren't making progress here.

allman

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Nov 2008 10:09:32 -0800

>   + Fernando's draft is mis-named.  Maybe we could get it changed.

 Defending Against Source Port Number Attacks

(ala RFC1948?)

>     clear in the text that obfuscation is the real point.

Same for 1948...

Joe