Fernando Gont <[email protected]> wrote on 04/03/2010 09:07:25 AM:
> Re: Gen art LC+TC review of: draft-ietf-tsvwg-port-randomization-06
>
> Fernando Gont
>
> to:
>
> Avshalom Houri
>
> 04/03/2010 09:07 AM
>
> Cc:
>
> michael.larsen, General Area Review Team, Russ Housley, jmpolk,
lars.eggert
>
> Hello, Avshalom,
>
> Some comments inline...
>
>
> > Summary: The document is not ready for publication as a BCP.
> >
> > Major issues:
> >
> > The document is lacking explanation on the when and how that the
> > techniques that are
> > described in the document will be used.
>
> Not sure what you mean. Port randomization is not used in any specific
> case. Transport protocols should randomize their ephemeral ports by
default.
Since the document is a BCP and port randomization is not part of the
basic
transport protocols it is important to explain the use case of what is
described
in the document. For example, are there environments where the port
randomization
is less important? What are the risks of not using this etc. Maybe the
right word
for what I am missing is "context". A good introduction can also help in
getting
a better security consideration section as it will be easier to refer to
the use
cases.
>
>
> > There are many ways to protect
> > the network
> > and it is not clear when and how the specific techniques that are
> > described in the
> > document will be used, how they relate to other ways etc.
>
> Port randomization mitigates off-path attacks by obfuscation. It simply
> requires more work on the side of the attacker for him to successfully
> forge a valid attack packet.
See my reply above.
>
>
>
> > Minor issues:
> >
> > Lines 624-626
> > However, it
> > may be affected by the vector involving binding a more specific
> > socket.
> > -- Not clear
>
> I have clarified the text.
>
> This is how I've modified it:
>
> --- cut here ---
> Port numbers that are currently in use by a TCP in the LISTEN state
> should not be allowed for use as ephemeral ports. If this rule is
> not complied with, an attacker could potentially "steal" an incoming
> connection to a local server application in at least to different
to->two
> ways. Firstly, an attacker could issue a connection request to the
> victim client at roughly the same time the client tries to connect to
> the victim server application [CPNI-TCP] [I-D.gont-tcp-security]. If
> the SYN segment corresponding to the attacker's connection request
> and the SYN segment corresponding to the victim client "cross each
> other in the network", and provided the attacker is able to know or
provided the -> provided that the
> guess the ephemeral port used by the client, a TCP simultaneous open
> scenario would take place, and the incoming connection request sent
> by the client would be matched with the attacker's socket rather than
> with the victim server application's socket. Secondly, an attacker
Very long sentence from Firstly.
> could specify a more specific socket than the "victim" socket (e.g.,
> specify both the local IP address and the local TCP port), and thus
> incoming SYN segments matching the attacker's socket would be
> delivered to the attacker, rather than to the "victim" socket (see
> Section 10.1 of [CPNI-TCP]).
>
> [....]
>
> The aforementioned issue do not affect SCTP, since most SCTP
do->does
> implementations do not allow a socket to be bound to the same port
> number unless a specific socket option (SCTP_REUSE_PORT) is issued on
> the socket (i.e., this behavior needs to be explititly allowed
> beforehand). An example of a typical SCTP socket API can be found in
> [I-D.ietf-tsvwg-sctpsocket].
>
> DCCP is not affected by the exploitation of "simultaneous opens" to
> "steal" incoming connections, as the server and the client state
> machines are different [RFC4340]. However, it may be affected by the
> vector involving binding a more specific socket. As a result, those
This is the first mention of the word "vector" in the document. Some
explanation may help.
> tuples {local IP address, local port, Service Code} that are in use
> by a local socket should not be allowed for allocation as ephemeral
be allowed for allocation -> allocated
> ports.
> --- cut here ---
>
> Does this change address your comment?
See comments above.
>
>
>
> > Lines 644-645
> > Ephemeral port selection algorithms SHOULD use the largest possible
> > port range, since this improves obfuscation.
> >
> > -- Should be merged with lines 632-634
> > As mentioned in Section 2.1, the dynamic ports consist of the range
> > 49152-65535. However, ephemeral port selection algorithms should
use
> > the whole range 1024-49151.
>
> Please let me know if you feel strongly about this. -- me, I believe the
> explanation *between* the two paragraphs is needed.
>
How this sounds to you?
As mentioned in Section 2.1, the dynamic ports consist of the range
49152-65535. However, ephemeral port selection algorithms should use
the whole range 1024-49151 since ephemeral port selection algorithms
SHOULD use the largest possible port range, as this improves
obfuscation.
Since this range includes ports numbers assigned by IANA, this may
not always be possible, though. A possible workaround for this
potential problem would be to maintain a local list of the port
numbers that should not be allocated as ephemeral ports. Thus,
before allocating a port number, the ephemeral port selection
function would check this list, avoiding the allocation of ports that
may be needed for specific applications.
>
> > Lines 1040-0144
> > The smaller the value of "N", the more linear the more
> > similar this algorithm is to the traditional BSD port selection
> > algorithm (described in Section 2.2. The larger the value of "N",
> > the more similar this algorithm is to the algorithm described in
> > Section 3.3.1 of this document.
> >
> > -- Need to rephrase
>
> Fixed.
>
>
>
> > Nits/editorial comments:
> >
> > Line 512:
> > There are a number of factors to consider when designing an
algorithm
> > -> There are number of factors to consider when designing an
algorithm
>
> Changed it to "There are several factors..."
>
>
>
>
> > Line 622
> > DCCP is not affected is not affected by the exploitation of
> > -> DCCP is not affected by the exploitation of
>
> Fixed.
>
>
> >
> > Line 799
> > will not have different sequences of port numbers; i.e., wil not be
> > -> will not have different sequences of port numbers; i.e., will
not be
>
> Fixed.
>
>
>
> > Line 869
> > availability an the granularity requested. With SCTP both
hostnames
> > -> availability and the granularity requested. With SCTP both
hostnames
>
> Fixed.
>
> Thanks!
>
> Kind regards,
> --
> Fernando Gont
> e-mail: [email protected] || [email protected]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
