Subject: Re: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization

From: Lars Eggert <[email-masked]>
Date: Wed, 4 Jul 2007 13:34:42 +0300

On 2007-5-31, at 17:51, ext Lars Eggert wrote:
> The concepts in this draft are likely relevant to most of our  
> transport protocols, and hence would be in scope for TSVWG. The  
> TSVWG chairs are interested in comments on whether there is group  
> interest in this draft - please comment on [email-masked].

We've received some positive feedback on adopting this draft, but I'd  
like to see a stronger show of support, because this draft impacts  
several of our transport protocols at the same time.

Please comment on [email-masked] - reply-to set accordingly.

Lars

---

From: Murari Sridharan <[email-masked]>
Date: Thu, 26 Jul 2007 07:42:42 -0700

In this context I wanted to bring up a related issue that might also strengthen this sort of a port randomization proposal.

Today the 64k port limitation is starting to become a huge problem and most often admins add ip addresses to increase the scalability. Given that most often the destination port (and sometimes the destination address) is well known, the only scalability left is the source address. Increasing ip addresses to improve scalability seems a fairly round about approach and frankly doesn't scale well. Given that the 64k limit is not fundamental why not provide a scaling factor similar to the receive window to scale the number of usable ports. This also makes randomization much more meaningful because in certain proxy scenarios the number of connections quickly exhausts the available ports and at that point the attacker can simply use any port assuming he can guess the source address.

Murari

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]]
Sent: Wednesday, July 04, 2007 3:35 AM
To: tsvwg WG
Cc: [email-masked]; DCCP mailing list; ext Fernando Gont; TSV Dir
Subject: Re: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization

Lars

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Thu, 26 Jul 2007 07:56:11 -0700

Murari,

I agree it is good idea to have an extended port range. But dearth of
ports is one such issue. We could argue the same about TCP options
(there are few drafts which never moved forward, AFAIK). Also you can
argue he same about TCP seq#/ack# for better security reasons. I think
Mark Allman wrote a document TCPx2 (or something) which basically
doubles the TCP header (64 bit seq/ack, 32 ports etc.,) So some of the
questions which might come up (aka possible ways of achieving this)

- why not have complete change to TCP header ?(like Mark's draft is
suggesting). Obviously it almost like "TCP v6". Lots of change needed
everywhere :-)

- or do it in piecemeal, first buy more TCP option space, standardize
any one of the proposals for extending the TCP option space. Then have
an extended port option like yu suggest below. Then think about other
TCP fields requiring extension.

Just a few thoughts.

-Anantha

> From: Murari Sridharan [mailto:[email-masked]] 
> Sent: Thursday, July 26, 2007 7:43 AM
> To: tsvwg WG
> Cc: [email-masked]; [email-masked]; DCCP mailing list; Fernando 
> Gont; TSV Dir
> Subject: RE: [Tsvwg] Re: [tcpm] Revision 
> ofdraft-larsen-tsvwg-port-randomization
> 
> In this context I wanted to bring up a related issue that 
> might also strengthen this sort of a port randomization proposal.
> 
> Today the 64k port limitation is starting to become a huge 
> problem and most often admins add ip addresses to increase 
> the scalability. Given that most often the destination port 
> (and sometimes the destination address) is well known, the 
> only scalability left is the source address. Increasing ip 
> addresses to improve scalability seems a fairly round about 
> approach and frankly doesn't scale well. Given that the 64k 
> limit is not fundamental why not provide a scaling factor 
> similar to the receive window to scale the number of usable 
> ports. This also makes randomization much more meaningful 
> because in certain proxy scenarios the number of connections 
> quickly exhausts the available ports and at that point the 
> attacker can simply use any port assuming he can guess the 
> source address.
> 
> Murari
> 
> > transport protocols, and hence would be in scope for TSVWG. 
> The TSVWG 
> > chairs are interested in comments on whether there is group 
> interest 
> > in this draft - please comment on [email-masked].
> 
> We've received some positive feedback on adopting this draft, 
> but I'd like to see a stronger show of support, because this 
> draft impacts several of our transport protocols at the same time.
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tcpm
>

---

From: Murari Sridharan <[email-masked]>
Date: Thu, 26 Jul 2007 08:05:08 -0700

We'll I guess we need things to be incrementally deployable so I think piecemeal is more practical. Having said that I am very cautious about any extensibility proposal, primarily around non-compliant devices which makes even incremental deployment slow down to a crawl, like the problems we are seeing with enabling WS by default. Given this option has been around forever and still causes significant connectivity problems so piecemeal options are not a cake walk either.

-----Original Message-----
From: Anantha Ramaiah (ananth) [mailto:[email-masked]]
Sent: Thursday, July 26, 2007 7:56 AM
To: Murari Sridharan; tsvwg WG
Cc: [email-masked]; [email-masked]; DCCP mailing list; Fernando Gont; TSV Dir
Subject: RE: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization

Murari,

Just a few thoughts.

-Anantha

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 26 Jul 2007 08:26:35 -0700

> TCP fields requiring extension.

SCTP already addresses most of these points, and is already an RFC.
In my opinion, any proposal to radically "fix" TCP needs to learn  
from the
deployment barriers that SCTP has faced and come up with a better plan.
If you aren't going to be completely transparent to all existing  
middleboxes,
then there really isn't any reason not to simply declare SCTP to be  
"new TCP".

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Thu, 26 Jul 2007 08:37:19 -0700

Caitlin,
 
> In my opinion, any proposal to radically "fix" TCP needs to 
> learn from the deployment barriers that SCTP has faced and 
> come up with a better plan.
> If you aren't going to be completely transparent to all 
> existing middleboxes, then there really isn't any reason not 
> to simply declare SCTP to be "new TCP".

Agreed. 

OTOH, adding more TCP option space should not be treated as a radical
change to TCP. Also the original email and the draft reference was more
about doing some things (like port randomization) which would help
increase the robustness of a some protocols, including TCP. Currently
there is no way to do this (without limiting the options which you can
send in the SYN) without increasing the TCP option space since it is
getting over-subscribed these days.

-Anantha

---

From: Lars Eggert <[email-masked]>
Date: Thu, 26 Jul 2007 10:46:53 -0500

Please focus the discussion in this thread around the document draft- 
larsen-tsvwg-port-randomization and start new threads for discussions  
on other topics, such as extending the port number space.

Lars

---

From: Murari Sridharan <[email-masked]>
Date: Thu, 26 Jul 2007 09:03:54 -0700

Aren't these directly related? Port randomization in general is good and agreed not all scenarios exhaust ports but attacks typically are on loaded servers and proxies, and if ports get exhausted in these key scenarios where such a draft makes most sense, what's the point of randomization?

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]]
Sent: Thursday, July 26, 2007 8:47 AM
To: ext Anantha Ramaiah (ananth)
Cc: Caitlin Bestler; tsvwg; Fernando Gont; Murari Sridharan
Subject: Re: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization

Lars

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 26 Jul 2007 09:08:18 -0700

On Jul 26, 2007, at 9:03 AM, Murari Sridharan wrote:

> Aren't these directly related? Port randomization in general is  
> good and agreed not all scenarios exhaust ports but attacks  
> typically are on loaded servers and proxies, and if ports get  
> exhausted in these key scenarios where such a draft makes most  
> sense, what's the point of randomization?
>
>
Port randomization is admittedly a limited solution, but it is a  
fully compatible solution.
More general solutions, while theoretically better, will likely have  
deployment barriers
that will actually make them even more limited as a solution.

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Jul 2007 11:58:00 -0700

Murari Sridharan wrote:
> In this context I wanted to bring up a related issue that might also
strengthen this sort of a port randomization proposal.
> 
> Today the 64k port limitation is starting to become a huge problem
> and
> most often admins add ip addresses to increase the scalability. Given
> that most often the destination port (and sometimes the destination
> address) is well known, the only scalability left is the source address.
> Increasing ip addresses to improve scalability seems a fairly round
> about approach and frankly doesn't scale well. Given that the 64k limit
> is not fundamental why not provide a scaling factor similar to the
> receive window to scale the number of usable ports. This also makes
> randomization much more meaningful because in certain proxy scenarios
> the number of connections quickly exhausts the available ports and at
> that point the attacker can simply use any port assuming he can guess
> the source address.

Scale works for windows because of two things:

1) the scale increases the granularity of the window info

2) the scale factor can be negotiated during SYN exchange

Neither is true for ports.

1-p) ports are specific numbers; extended fields could be provided in
options, but that's equivalent to having the port number itself in an
option anyway

2-p) we can negotiate the use of these extended port ranges with
endpoints, but it will break NATs

Portnames is a step in these directions, but is currently experimental
at best. See
http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt (to be
updated shortly).

Joe

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Jul 2007 11:59:22 -0700

> Murari,
...
> TCP fields requiring extension.

The problem is that buying more option space is equivalent to requiring
a whole new TCP header - it has the same problems with backward
compatibility. Previous attempts explored this space, and I think this
was Mark's motivation for a doubled-field TCP header.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Jul 2007 12:03:42 -0700

Caitlin Bestler wrote:
>> Aren't these directly related? Port randomization in general is good
>> and agreed not all scenarios exhaust ports but attacks typically are
>> on loaded servers and proxies, and if ports get exhausted in these key
>> scenarios where such a draft makes most sense, what's the point of
>> randomization?
>>
>>
> Port randomization is admittedly a limited solution, but it is a fully
> compatible solution.

Port randomization isn't really a 'solution' to port exhaustion; it's a
BCP-ish recommendation that's like ISN-randomization. It helps a bit and
it's low cost.

Port exhaustion, BTW, also can mean two things:
	a- we need more ports for services
	b- it's too easy to scan all port pairs to attack

Portnames and/or tcp-x2 (I think that's what Mark called it) address the
first issue. The second is, IMO, better addressed with proper security,
rather than haystack-hiding of a needle.

Joe

---

From: Murari Sridharan <[email-masked]>
Date: Thu, 26 Jul 2007 12:13:54 -0700

Agree on the NAT part.

However whether or not its negotiated during SYN exchange would depend on how it gets specified. For instance (again I really am thinking real-time and aloud here not fully thought thru) we could do something like the following. On the SYN packet, the sender picks a port (unscaled)and tries to negotiate a scaling option, (NATs that do packet inspection are free to strip this option out) and the destination picks a port and may respond to the scaling. If both sides agreed, then the scaled ports are used for the 4-tupe, if not the unscaled version is used. The only caveat is that while a connection attempt is in progress to a destination, we cannot be trying the same local port, since till the 3-way handshake completes you wont know whether the scaled or the unscaled version is going to be used.

I am not suggesting that scaling ports is a good option, just a thought. I will look at the portnames draft.

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Thursday, July 26, 2007 11:58 AM
To: Murari Sridharan
Cc: tsvwg WG; [email-masked]; DCCP mailing list; Fernando Gont; TSV Dir
Subject: Re: [Tsvwg] Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization

>
> Today the 64k port limitation is starting to become a huge problem and
> about approach and frankly doesn't scale well. Given that the 64k
> limit is not fundamental why not provide a scaling factor similar to
> the receive window to scale the number of usable ports. This also
> makes randomization much more meaningful because in certain proxy
> scenarios the number of connections quickly exhausts the available
> ports and at that point the attacker can simply use any port assuming
> he can guess the source address.

1-p) ports are specific numbers; extended fields could be provided in options, but that's equivalent to having the port number itself in an option anyway

2-p) we can negotiate the use of these extended port ranges with endpoints, but it will break NATs

Portnames is a step in these directions, but is currently experimental at best. See http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt (to be updated shortly).

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Jul 2007 12:18:18 -0700

Murari Sridharan wrote:
> Agree on the NAT part.
> 
> However whether or not its negotiated during SYN exchange would
> depend
> on how it gets specified. For instance (again I really am thinking
> real-time and aloud here not fully thought thru) we could do something
> like the following. On the SYN packet, the sender picks a port
> (unscaled)and tries to negotiate a scaling option, (NATs that do packet
> inspection are free to strip this option out) and the destination picks
> a port and may respond to the scaling. If both sides agreed, then the
> scaled ports are used for the 4-tupe, if not the unscaled version is
> used. The only caveat is that while a connection attempt is in progress
> to a destination, we cannot be trying the same local port, since till
> the 3-way handshake completes you wont know whether the scaled or the
> unscaled version is going to be used.

It can't get negotiated during the SYN; NATs wouldn't track that, and
will break the connection if it 'moves' to another port.

Even if it is in the SYN, it won't allow two hosts to share a port
through a NAT.

It's worth looking at the alternatives which are discussed in Mark's ID
and mine, too.

Joe

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Thu, 26 Jul 2007 12:30:21 -0700

Lars had sent an email to retain focus on the port randomization and
hence this is going to my last comment... Pl see inline..
 
> The problem is that buying more option space is equivalent to 
> requiring a whole new TCP header - it has the same problems 
> with backward compatibility. Previous attempts explored this 

New TCP header == "Mountain" , IMO this is equivalent to using SCTP in
some sense.

TCP option space == "Molehill" , this is a "minimal" change with "some"
backward compat issues which can be addressed.

If I take your above para seriously, then you are in a way implying that
there is no new TCP options possible :-( or in other words users of TCP
would be rationed to use only a few options in the initial SYN exchange.

-Anantha
> space, and I think this was Mark's motivation for a 
> doubled-field TCP header.
> 
> Joe
> 
> --

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Jul 2007 12:36:12 -0700

changing the thread as Lars suggested...

> backward compat issues which can be addressed.

See my other post; it's impossible to extend TCP option space for SYNs,
and SYNs are where they matter.

> would be rationed to use only a few options in the initial SYN exchange.

New options are possible, but only if they are OPTIONAL and we expect
their use to be mutually exclusive with likely SYN options (SACK,
timestamps) or other proposed options. Or we should start making
progress to Mark's idea of just breaking things now.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Jul 2007 03:19:53 -0300

At 12:37 26/07/2007, Anantha Ramaiah \(ananth\) wrote:

>increase the robustness of a some protocols, including TCP.

Exactly. What we propose is a local policy for selecting ephemeral 
ports. We do not propose any change to the syntax or semantics of any 
TCP field.

The policies we propose can be deployed incrementally, and aome of 
them already ship with a number of operating systems (including 
Linux, FreeBSD, and OpenBSD).

Kindest 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, 30 Jul 2007 03:25:41 -0300

At 13:03 26/07/2007, Murari Sridharan wrote:

>on loaded servers and proxies, and if ports get exhausted in these 
>key scenarios where such a draft makes most sense, what's the point 
>of randomization?

Not necessarily. The RST attacks (and others) on which we are still 
working at tcpm wg typically target BGP routers, for which port 
numbers are usually *not* exhausted.

Port randomization is a general (and proactive) mitigation technique 
for off-path (blind attacks). It is cheap, and can be deployed incrementally.

Yes, there may be scenarios in which port numbers may have been 
exhausted, and thus port randomization might not be of much help. For 
those scenarios, you may need something else (probably not as cheap, 
and probably not as easy to deploy).

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Jul 2007 03:19:53 -0300

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Jul 2007 03:25:41 -0300

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Jul 2007 03:14:54 -0300

At 11:42 26/07/2007, Murari Sridharan wrote:

>and most often admins add ip addresses to increase the scalability. 
>Given that most often the destination port (and sometimes the 
>destination address) is well known, the only scalability left is the 
>source address. Increasing ip addresses to improve scalability seems 
>a fairly round about approach and frankly doesn't scale well. Given 
>that the 64k limit is not fundamental why not provide a scaling 
>factor similar to the receive window to scale the number of usable 
>ports. This also makes randomization much more meaningful because in 
>certain proxy scenarios the number of connections quickly exhausts 
>the available ports and at that point the attacker can simply use 
>any port assuming he can guess the source address.

While I may agree with increasing the range of port numbers, I think 
this is out of the scope of the port randomization draft we have authored.

There are a few things that may be worth noting:

* The port randomization approaches discussed in the port 
randomization draft are independent of the range of ephemeral ports. 
That is, even if at some point we decide to scale the port numbers 
(or whatever), the approaches discussed in the port randomization 
draft would still apply.

* Most TCP implementations use for the ephemeral ports a very small 
subspace eg, ports 1024-4999) of the available port number space. 
That is, you may be using 1/10th of the range you have available. In 
this respect, our port randomization draft advises to increase the 
port number range used for ephemeral ports. This may help a bit in 
the scenarios you are describing.

Kind regards,