Subject: Re: Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Apr 2009 18:24:52 -0300

Folks,

Some last call comments:

* The document never mentions the fact that this document is
IPR-encumbered. As far as I recall, much of the dicussion within tcpm
with respect to the level of requirements of this document
(MAY/SHOULD/MUST, etc.) had to do with this fact. I believe the document
should include a warning mentioning that there's an IPR on the document,
so that implementers can consider this point in their decision of
whether to implement the described mechanisms or not.

* The document discusses blind attacks, and to some extent assesses the
difficulty in guessing the four-tuple that identifies a TCP connection.
However, it does not even mention port randomization, which is probably
the most simple and straightforward approach for mitigating blind
attacks against TCP. This was raised by me and other quite a few times
in the tcpm wg list, pre and post wglc, but this comment was never
addressed. It's particularly curious that port randomization is not
mentioned when tsvwg is working on it (draft-ietf-tsvwg-port-randomization).

* Among the factors that determine how easy these attacks be exploited
is the window size. This document should provide, at the very least,
pointers with advice on what to do with the tcp window. While quickly
skimming through RFC 4953, it seems it has some advice on the TCP
window. We do offer a lengthy discussion of this and other issues in
draft-gont-tcp-security and
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf

* Yet another factor is TCP ISN randomization. At the very least, this
document could/should a pointer to RFC 1948. We do offer a lengthy
discussion of this and other issues in draft-gont-tcp-security and
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf

* Just of the top of my head: Hadn't the BGP spec been updated so that a
well-known port was not required as the *source* port?

* The counter-measure of for the SYN-based reset attack may have missed
a common heuristics for the handling of SYN segments. See pages 86 and
87 of the UK CPNI paper on TCP security. FWIW, we argue that the
processing of SYN segments proposed in [Ramaiah et al, 2008] should
apply only for connections in any of the synchronized states other than
the TIME-WAIT state.

* When it comes to TCP-based blind-connection reset attacks, there's a
much more trivial -- yet not discussed before? -- alternative. See
Section 11.1.3 and Section 11.1.4 in draft-gont-tcp-security and the
CPNI paper
(http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf).
These variants should, at the very least, be mentioned and a pointer
provided to them as, at least in theory, are much easier to exploit.

* When it comes to the data injection attack, Michael Zalewski sketched
another attack vector which may be easier to exploit. We discuss it in
Section 16.2 of draft-gont-tcp-security and the CPNI doc, along with
advice. IMO, this vector should be mentioned, too.

Needless to say, I'm in favor of improving the robustness of TCP and,
IPRs-aside, I'm happy with the implementation of the counter-measures
described in the tcpsecure I-D (all three).

I'm also glad that this doc is getting close to publication. Five years
working on a document is quite a lot of time! (yes, it could have been
worse, some might argue).

Thanks!

Kind regards,
Fernando Gont

The IESG wrote:
> The IESG has received a request from the TCP Maintenance and Minor 
> Extensions WG (tcpm) to consider the following document:
> 
> - 'Improving TCP's Robustness to Blind In-Window Attacks '
>    <draft-ietf-tcpm-tcpsecure-11.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2009-04-16. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-11.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11735&rfc_flag=0
> 
> The following IPR Declarations may be related to this I-D:
> 
> https://datatracker.ietf.org/ipr/421/ 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 

-- 
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: Fri, 17 Apr 2009 04:14:36 -0100

On Mon, Apr 13, 2009 at 10:23 PM, Anantha Ramaiah (ananth)
<[email-masked]> wrote:

> > IPR-encumbered. As far as I recall, much of the dicussion
> > within tcpm with respect to the level of requirements of this
> > document (MAY/SHOULD/MUST, etc.) had to do with this fact. I
> > believe the document should include a warning mentioning that
> > there's an IPR on the document, so that implementers can
> > consider this point in their decision of whether to implement
> > the described mechanisms or not.
>
> I am confused what to do since this is being brought up very late in the
> game. That said, there are *many* drafts/RFC's that have IPR on them in
> the whole of ietf. Do all them explicitly state the IPR link ? I'll
> leave it to the collective wisdom of the group and the chairs to offer
> guidance on this matter.

I personally believe this should be noted in all RFCs on which there's
a known IPR. However, Joel Halpern mentioned this is not current
practice. If that's the case, I'd have no problem with leaving it "as
is". (FWIW, if you look at our tcp-security document, we do recommend
the implementation of the counter-measures you propose, but just note
that there's an IPR, and that implementers should research how this
would affect them).

> > * The document discusses blind attacks, and to some extent
> > assesses the difficulty in guessing the four-tuple that
> > identifies a TCP connection.
> > However, it does not even mention port randomization, which
> > is probably the most simple and straightforward approach for
> > mitigating blind attacks against TCP. This was raised by me
>
> Well, the point is that source port randomization is something external
> like Ipsec and nothing specfic to TCP. TCP will work with or without src
> port randomization.

I disagree. Port numbers are a TCP mechanism. How you select them is a
TCP policy. The fact that there's no mandatory policy for selecting
the port numbers doesn't mean that they things like "port
randomization" are external.

> Now the scope of this document is to improve
> robustness to TCP esp. in cases where the TCP connection is not
> protected by other means like TCP MD5 or TCP AO etc., Now this point is
> very clear in the document. That said I have no issues putting a
> reference to the port randomization in the document.

What I mean is that anybody that cares about this stuff (FWIW, I do)
would also implement port randmization, ISN randomization, etc. One
might argue that there's no use in enforcing the more strict
validation checks in your document if the stack uses easily
predictable (and global) ISNs, and easily predictable ports for the
outgoing connections.

> > and other quite a few times in the tcpm wg list, pre and post
> > wglc, but this comment was never addressed. It's particularly
> > curious that port randomization is not mentioned when tsvwg
> > is working on it (draft-ietf-tsvwg-port-randomization).
>
> Yes, you did raise this issue last time, but I did defer it to the WG
> and did not receive any response, so I simply left it at that.

IIRC, both Joe and me had agreed on this one (yeah, we did :-) ).

> > * Among the factors that determine how easy these attacks be
> > exploited is the window size. This document should provide,
> > at the very least, pointers with advice on what to do with
> > the tcp window. While quickly skimming through RFC 4953, it
>
> It does mentions about the window size relationship, For example in the
> beginning sections of the document we briefly mention the window size
> and the # of packets that is required to generate a successful attack.

What I mean is: you should not use windows that are larger than
necessary. Using larger windows than necessary doesn't come for free
(e.g., it increases the chances of an attacker of successfully
performing these attacks).

> > * Yet another factor is TCP ISN randomization. At the very
> > least, this document could/should a pointer to RFC 1948. We
> > do offer a lengthy discussion of this and other issues in
> Why should it talk about ISN randomization since ISN randomization, is
> somewhat orthogonal to the type of attack here, it is not even one of
> the attack vector.

If I can predict the ISN, I don't have to guess it. Therefore, it's
easier to successfully perform the attack.

> We could refer this, but the scope of the current document is about the
> RST/SYN and Data attacks and mitigations, Since this document generally
> refers RFC 4953 (which came after this document was written. BTW) I
> think this should suffice, IMO.

I believe you should say something about this. How you address this is
a matter of choice. e.g., you could craft your own text (just mention
that sequence numbers should be generated in such a way that are not
easily guessable by an off-path attacker), reference RFC 1948, or
reference the work with did in the tcp-security I-D.

> > * The counter-measure of for the SYN-based reset attack may
> > have missed a common heuristics for the handling of SYN
> > segments. See pages 86 and
> > 87 of the UK CPNI paper on TCP security. FWIW, we argue that
> > the processing of SYN segments proposed in [Ramaiah et al,
> > 2008] should apply only for connections in any of the
> > synchronized states other than the TIME-WAIT state.
>
> We just followed RFC 793 as the base and the changes are made w.r.t
> that. TIME-WAIT may be an exception but doesn't RFC 793 already has that
> language correct?

Well, the timestamps was published *after* RFC 793. So RFC imsply
doesn't address this, because timestamps didn't exist at the time.

> > * When it comes to TCP-based blind-connection reset attacks,
> > there's a much more trivial -- yet not discussed before? --
> > alternative. See Section 11.1.3 and Section 11.1.4 in
> > draft-gont-tcp-security and the CPNI paper
> > These variants should, at the very least, be mentioned and a
> > pointer provided to them as, at least in theory, are much
> > easier to exploit.
>
> Those sounds like some new proposals (security and precedence) different
> stacks would have taken different measures to address this issue.
> Anyways this is something new and hence needs more discussion and
> evaluation. Has these ideas been submitted in a draft to TCPM? (your
> recent BCP document tcp-security, covers it ?)

Yes, the tcp-security I-D covers it. This stuff came as a surprise
while assessing RFC 793. One would expect that these attacks don't
work in practice--- but you never know. However, IETF-wise they do...
therefore I think it should be mentioned as another potential
connection-reset attack vector (*much* easier, as you don't even have
to guess the sequence number)

> > * When it comes to the data injection attack, Michael
> > Zalewski sketched another attack vector which may be easier
> > to exploit. We discuss it in Section 16.2 of
> > draft-gont-tcp-security and the CPNI doc, along with advice.
> > IMO, this vector should be mentioned, too.
>
> This again is an attack which relies on the IP functionality and not
> TCP.

This one I may grant.

> > I'm also glad that this doc is getting close to publication.
> > Five years working on a document is quite a lot of time!
>
> Agreed. Esp when it has been running in the internet with multiple
> vendors supporting these mitigations.

Agreed.

Thanks!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Apr 2009 09:03:02 +1200

On 2009-04-17 17:14, Fernando Gont wrote:
>>> IPR-encumbered. 
...

> that there's an IPR, and that implementers should research how this

Personal belief doesn't come into it. It's strictly defined in a BCP.
RFC3979 tells us the rules about this. Basically, the RFC Editor will
do what is required:

"4.  Actions for Documents for which IPR Disclosure(s) Have Been Received

   (A) When any Intellectual Property Right is disclosed before
       publication as an  RFC, with respect to any technology or
       specification, described in a Contribution in the manner set
       forth in Section 6 of this document, the RFC Editor shall ensure
       that the document include a note indicating the existence of such
       claimed Intellectual Property Rights in any RFC published from
       the Contribution.  (See Section 5 below.)"

[Section 5 defines the exact text to be included in such RFCs.
I believe you can use <?rfc iprnotified="yes"?> in xml2rfc.]

"11.  No IPR Disclosures in IETF Documents

   IETF and RFC Editor Documents must not contain any mention of
   specific IPR.  All specific IPR disclosures must be submitted as
   described in Section 6.  Specific IPR disclosures must not be in the
   affected IETF and RFC Editor Documents because the reader could be
   misled.  The inclusion of a particular IPR disclosure in a document
   could be interpreted to mean that the IETF, IESG, or RFC Editor has
   formed an opinion on the validity, enforceability, or applicability
   of the IPR.  The reader could also be misled to think that the
   included IPR disclosures are the only IPR disclosures the IETF has
   received concerning the IETF document.  Readers should always refer
   to the on-line web page to get a full list of IPR disclosures
   received by the IETF concerning any Contribution.
   (http://www.ietf.org/ipr/)"

      Brian

---

From: "Faheem Syed Muhammed" <[email-masked]>
Date: Sat, 18 Apr 2009 12:26:58 +0400

Hello All

This is Faheem. 

I am not sure if I have transgressed by using this forum to seek help to
setting up DHCPv6 in a test LAB. 

For last six months I and my team are busy setting up IPv6 in a test lab. So
far we have succeeded in the following:

LAN
 Dual stack host machines (Windows XP, Vista and Windows 7)
 Servers, Dual Stack (Windows Server 2003 and 2008)

WAN (Leased Line link of 2Mbps capacity)
 Cisco Routers running IPv6 enabled IOS (Dual Stack and IPv6 only Config,
both cases)
 RIPv6

The communication is happening on the network (LAN & WAN) very well with
static IPv6 address assignments. Local hosts file are doing right
resolutions. Windows server 2003 doesn't offer stateful address allocation
while Windows server 2008 does allow this feature but practically speaking
XP and Vista clients seem to be not aware of such a server on LAN. Windows 7
gets the IP address but couldn't communicate with other machines and says
"General Transmit Failure" error. The same machines when given static IP
address works very well.

Objectives:
 To have a stateful IPv6 DHCP addresses assignment so the clients are
populated in a controlled manner, especially in a typical office
environment. 

I wish if I could get help to setting up a DHCPv6 Server offering stateful
address assignment and would allow to advertise server options too like
default gateway, preferred DNS servers. Our current scenario is based on
Windows Servers offering DNS, PROXY, File Sharing, and DHCPv4 services.
Every client which comes on LAN, is known to administrators and have group
policies enforced.

We have tried Dibbler on Linux and Windows both but in turn it has its own
practical limitations that wouldn't fit in our scenario.

Thanking You
Faheem Syed Muhammed