RE: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization

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:ananth@cisco.com]
Sent: Thursday, July 26, 2007 7:56 AM
To: Murari Sridharan; tsvwg WG
Cc: ext@cisco.com; tcpm@ietf.org; DCCP mailing list; Fernando Gont; TSV Dir
Subject: RE: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization

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

> -----Original Message-----
> From: Murari Sridharan [mailto:muraris@microsoft.com]
> Sent: Thursday, July 26, 2007 7:43 AM
> To: tsvwg WG
> Cc: ext@cisco.com; tcpm@ietf.org; 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
>
> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com]
> Sent: Wednesday, July 04, 2007 3:35 AM
> To: tsvwg WG
> Cc: tcpm@ietf.org; DCCP mailing list; ext Fernando Gont; TSV Dir
> Subject: Re: [Tsvwg] Re: [tcpm] Revision of
> draft-larsen-tsvwg-port-randomization
>
> 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 tsvwg@ietf.org.
>
> 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 tsvwg@ietf.org - reply-to set accordingly.
>
> Lars
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www1.ietf.org/mailman/listinfo/tcpm
>

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm