Subject: [tcpm] security draft: section 9 review

From: Mark Allman <[email-masked]>
Date: Mon, 04 Apr 2011 14:18:40 -0400

I talked with Wes a while back and agreed to review the congestion
control section of the security document (section 9).  To try to
calibrate myself I also read through the intro.

In sum, I basically find this section to be 15 pages of re-hash that
adds little if anything to the state of our understanding.

Section 1:

  + The premise of this document seems strange to me.  Basically, the
    reviewed documents don't consider security or people don't read them
    or whatever and so we have to invent a new 100+ page document that
    nobody will read to fix this situation.  Huh.

  + The older of the TCP documents may not consider security as well as
    we'd like, but the newer documents do consider security and in some
    cases at least as well as this document.  So, perhaps there are
    things to be done to older documents to shore them up, but I am not
    entirely sure there is any value in re-visiting the newer documents
    and parroting back what is said in those in some new document.

  + I wonder if there is a different route here which is along the lines
    of spelling out what a modern TCP looks like and then trying to go
    after issues that *are not* addressed by the documents themselves.
    E.g., who cares about blind dupack attacks in a world that to an
    exceedingly large degree uses SACK?  It is not necessarily a service
    to anyone to discuss things that don't matter a ton---and in a way
    that isn't all that different from the current standards.

As far as I can tell section 9 makes three recommendations over and
above the RFCs:

  - Stricter check on out-of-window packets to prevent blind attackers
    from using this check to strobe out valid ACKs once they guess the
    four-tuple.

    I don't have a lot of heartburn with the proposed check except that
    there is an extra approximately 112 pages used to describe it than
    would be necessary.

  - Stronger language about the number of dupacks a TCP sender should
    expect from a correctly behaving TCP receiver.  I.e., this document
    (on page 765) says a TCP SHOULD limit the number of dupacks it will
    honor and RFC 5681 says a TCP MAY limit the number (on page 10).
    Perhaps the mechanism ought to be a SHOULD and not a MAY.  But, in a
    SACK-dominated world I have a hard time getting worked up over it
    one way or the other.  And, changes of this level perhaps should get
    20sec in the emacs buffer to change MAY to SHOULD in 5681, be WGLCed
    for two weeks and be put in the actual main document.  (Not that I
    think it is important enough to do so ...)

  - Recommendation against the penalty box for flows not responding to
    ECN.  In particular, the draft worries about forged segments causing
    a flow to appear non-responsive and then reset.  Fine, fair enough.
    Penalty boxes come with pros and cons and that is a con.  I don't
    think penalty boxes are part of the standard and therefore this
    appears as merely a comment and so I am not sure if it is BCP
    material.  At best a BCP should probably flag the issue (rather than
    make a recommendation).  But, it isn't a TCP issue, per se, and so
    one wonders if a document aimed at TCP implementations is really
    going to get it in the hands of the right audience.  Or, if this is
    the right WG to worry about such things and make recommendations in
    that space.

OK, now comments on section 9:

  o RFC 2581 has been obsolete for 18 months.  Please change to RFC 5681
    and note that RFC 5681 changed in ways that are germane to this
    document so this is not cosmetic.  

  o I found the entire structure of the section to be a mess in both
    macroscopic and microscopic ways.  The whole things at least needs
    coherently organized.  (See below.)

  o 9.1.1 starts very abruptly with a "rule" without any context around
    it.  This formulation is carried throughout and its just damn
    weird.  It'd seem much more natural to tee up a problem and then
    give a mitigating rule.  My reaction to this "rule" was something
    like "in slow start?  congestion avoidance?  what in the hell is he
    talking about?".

  o This document says nothing over and above what RFC 5681 says about
    ACK division.  I.e., page 6 of RFC 5681 discusses exactly this
    for both slow start and congestion avoidance.

  o The upshot of 9.1.2 is a notion that TCPs SHOULD limit the number of
    acceptable dupacks.  This extends (slightly) the MAY that is in RFC
    5681 (page 10).  Further, it would seem nice to note here that
    SACK-based loss recovery (and all empirical evidence I have seen
    points to SACK being massively used) does not share these issues
    with dupack-based attacks and to try to put these attacks in
    perspective given the proportion of SACK-savvy hosts.

  o The figure references in this document are ridiculous.  You need to
    figure out how to explain things without figures in this document,
    or use diagrams or something.  What you have is essentially
    normative references to some tech report that someone has to look at
    to understand the text of this document.  Its an unreasonable
    construct.  Its fine to explain something that I can understand in
    this document and *also* point to a discussion/figure elsewhere, but
    don't require me to go look at it there.

  o 9.1.3: The authors beliefs about middleboxes are nice.  My daughter
    believes in the tooth fairy, too.  Seemingly in a document that is
    targeted at BCP we should strive for something a bit more concrete
    and citable than belief.

  o 9.1.3: There is not enough discussion around this attack.  In
    particular, there are two reasons why someone might want to do this
    attack.

    The first reason is for a receiver to try to coax a higher sending
    rate out of the sender for some transfer they care about.  The
    trouble---and it should at least be discussed---is that the user is
    walking a tightrope here.  They are coaxing out faster transmission,
    but as soon as a packet they have ACKed is lost its "game over" and
    they have to start a new connection.  Depending on how things work
    they might have to start the whole transfer over again.  Or, if
    their app protocol supports it perhaps they can restart things at
    the point of loss.  But, either way it takes complexity and time to
    fix things.  And, as the sending rate is coaxed faster the odds of
    taking a loss increase.  So, the attack somewhat works against
    itself and that makes it less compelling.  At least a document about
    security would want to understand the threat model, right?

    The second reason for optimistic ACKing is to hurt the network
    (i.e., Sherwood's work).  I.e., the recipient does not care about
    the data and so losses are immaterial.  Rather, the attacker wishes
    to coax the sender into blasting the network to congest the whole
    thing.  Different threat model.

  o The intro to 9.2 is a confusing mess.  I don't know what the hell it
    is trying to say and a bunch of stuff is then repeated later.

  o I basically fail to see how this blind attacks section is better
    than the one we already have in the form of Joe's RFC.  

  o There is a whole section on the difficulty of blind attacks and it
    basically boils down to "we have seen some cases where it is easy to
    guess the four tuple" and once we have done that then it is "not
    hard" to wedge enough out of window packets to the receiver between
    legit packets to mount these attacks.  Neither of these statements
    carries much evidence.  The truth of the matter is attacking
    arbitrary TCP connections in a blind fashion is incredibly
    difficult.  There are more predictable connections whereby one can
    get some of the four tuple and that makes things easier.  But, even
    if I give you a bit of that and the sequence number its still hard
    and it still takes a lot of packets.  And, even with your stronger
    "near in-window" check it is still possible.  The bottom line is
    that the community has recognized this and invented actual
    mechanisms---not heuristics---to prevent blind attacks.  And, yet
    there is *no* mention of these.  I have no idea how I am supposed to
    take this document seriously.

  o 9.2.4: It took me a bit of thinking to try to understand what in the
    hell you were talking about with respect to NewReno.  I finally
    think I figured it out, no thanks to the text.  Basically, I think
    you are saying that if I can wedge three dupacks into a NewReno
    connection then the connection will enter loss recovery and every
    legit ACK will look like it is pointing to a lost packet and
    therefore trigger a needless retransmit.  This bit needs completely
    re-written.

  o 9.2.4: Limited transmit... You're worried about two additional
    segments?  That is a security problem?  Really?  Off-the-rails
    insane. 

  o 9.2.5: SACK: Note 3517bis alters the definition of dupack to
    basically what is in this document.  I am pretty sure its safe to go
    ahead and reference that in this document as 3517bisbis will likely
    be done before this document.

  o 9.2.5: You move from one "TCP SHOULD ..." to the next with no
    warning.  Some sane sectioning or headings or something would really
    help a bunch here.

  o There is really nothing new in the ECN section.  All these
    things---as this document notes---are discussed elsewhere.

  o I don't follow the introduction of compromised routers when talking
    about ECN.  Why didn't you discuss those in terms of causing TCP
    slowdown attacks by dropping packets, say?  Or, by knocking down
    rwnd, say?  Or, by corrupting data, say?  Why all the sudden are
    malicious routers germane?  It makes no sense and just adds to the
    less-than-coherent rambling of this section.

  o There are any number of places in this section where things are just
    needlessly repeated.  Probably it stems from the structure, but it
    could see a massive cleanup so that you say something only once.

Things inexplicably not in the document:

  o There are two basic forms of attacks this document discusses.  The
    first is an attack involving one of the endpoints gaming the
    congestion control.  The other is a blind attacker.  This latter
    could be helped by TCP-AO and it seems curious that this is not even
    mentioned.

  o There is actually a third class of attacks and that is a third-party
    attack (i.e. not a participant) that is not blind.  I.e., someone
    sitting across a coffee shop.  TCPM's fascination with blind attacks
    aside this seems to me like a much more likely avenue for attack
    than a blind attack.  In this case, many of the attacks discussed in
    this document become quite possible and a whole lot easier.  And,
    even the protections discussed offer little help.  Again, TCP-AO
    would offer protection in these cases.

Sorry for the long email about such a short part of the document.  If
the rest of the document is like this then I don't see anything
compelling.  There may be some nuggets here or there (e.g., a tighter
check on out-of-window segments), but these new bits don't justify the
15 page section let alone a 100+ page document.  There has to be a
better way to more lucidly get those sorts of things into implementers'
hands. 

allman

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Apr 2011 19:02:12 -0300

Hi, Mark,

> adds little if anything to the state of our understanding.

I agree that it contains lots of background that should be removed.

>     nobody will read to fix this situation.  Huh.

The assessed documents do not consider security, or there are decisions
that need to be taken when one implements an RFC, on which the
aforementioned RFCs do not provide advice.

The document is large, and I should probably remove much (if not all) of
the background information that makes the document as large as it
currently is.

>     and parroting back what is said in those in some new document.

Maybe that when that's the case (i.e., everything is covered in the
curresponding RFC), this document should just say that, and that's it.

>     exceedingly large degree uses SACK?  

When I tested these attacks, they did work even for SACK-enabled
connections. I recall that we discussed this off-list, and that
something in this respect was added to the 2581bis document
("sack-enabled connections should validate dupacks by making sure that
they include new sack information" or the like). At the time, 2581bis
had not made it into an RFC (and the aforementioned changes had not been
ncorporated when the CPNI TCP document was published, IIRC). This might
be, as mentioned in my other post, a specific example on which
tcp-security is simply outdated.

Question: Any data regarding whether current implementations do validate
the dupacks for sack-enabled connections?

>     It is not necessarily a service
>     to anyone to discuss things that don't matter a ton

FWIW, I'm not arguing that e.g. these dupack attacks matter a lot. But
if they can be simply mitigated, I don't see why we should leave them in.

>     there is an extra approximately 112 pages used to describe it than

Agreed. I'm already working in removing much (probably most) of the text
in this section.

>     one way or the other.

Does sack, in practice, mitigate these attacks? (see above)

>     And, changes of this level perhaps should get

No objections to this. Actually, I think that I suggested this myself at
the time 2581bis was being produced.

>     document so this is not cosmetic.  

Will do.

>     weird.  
>     It'd seem much more natural to tee up a problem and then

Regarding the REQ/DISCUSSION format, this was actually requested some
time ago (i.e., reformat the document a la RFC1122). However, I do agree
that this should be better specified. At the very least, whether this is
during slow start, congestion avoidance, etc.

>     for both slow start and congestion avoidance.

As noted, tcp-security is outdated regarding RFC5681. I'll fix this.

>     perspective given the proportion of SACK-savvy hosts.

IIRC, last time I checked (2007), sack didn't make a difference. This
may have changed since then. I will try to re-run my tests.

>     don't require me to go look at it there.

Agreed. I think this is even noted in the "TODO list". This is editorial
work to be done. Meanwhile, I thought the wg might simply decide that
e.g. those figures were simply not necessary... hence no much sense in
doing ASCII-art for them.

>   o 9.1.3: There is not enough discussion around this attack.  

Agreed. But this is another instance of "should the document include
background stuff, or should it simply provide a reference to the
background stuff when such a thing is available?". Note that I'm not
arguing one way or another.

>     In

Agreed. Will do.

>     is trying to say and a bunch of stuff is then repeated later.

In the previous attacks, the attacker is one endpoint of the connection
(i.e., he attacks his own connection). In the attacks described in
Section 9.2, the attacker attacks a third-party connection. He forges
out-of-window packets, which elicit dupacks from the recipient of these
out-of-window packets. (and there's no need to hit the window...
actually, for these attacks to work the attack packets must *not* with
the window). -- I know you'll hate it, but this is better explained with
the figures in the PDF document (which are probably virtually impossible
to convert to ASCII art).

>     than the one we already have in the form of Joe's RFC.  

Joe's RFC does not cover these attacks. His RFCs covers *in-window*
attacks.

That aside, the unnumbered subsections "port randomization", "GTSM",
"ingress and egress filtering", etc., should be removed., or at least
summarized in a single paragraph.

>     legit packets to mount these attacks.  

Which section are you referring to?

>     Neither of these statements
>     there is *no* mention of these.  

What are the mechanisms that you're referring to? And what attack
vectors are you arguing that they apply to?

>     you are saying that if I can wedge three dupacks 

Actually, you cause one of the endpoints to wedge the dupacks -- you
don't do it yourself.

>     into a NewReno

Will do.

>     segments?  That is a security problem?  Really?  Off-the-rails

No. I'm not worried at all. This section simply answers the question
"what if limited retransmit is implemented?". Maybe what's missing is a
sentence that notes that this is not big deal.

>     be done before this document.

Will do.

>     warning.  Some sane sectioning or headings or something would really

Will do.

>     less-than-coherent rambling of this section.

I guess that this has to do with "what possible issues does ECN
introduce?" -- which I think is the same approach the SecCons of the ECN
RFC itself takes. That said, I think it's already noted in the document
that if you assume that the router has been compromising, then you're
already toast. --- probably that of playing with ECN would be the last
choice that an attacker would use.

>     could be helped by TCP-AO and it seems curious that this is not even

Agreed. Will do.

>     would offer protection in these cases.

You're right.

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

---

From: Mark Allman <[email-masked]>
Date: Wed, 06 Apr 2011 22:40:13 -0400

> I agree that it contains lots of background that should be removed.

I'm not going to waste WG bandwidth doing counter-point on my review.
Basically, I stand by my review in the face of your response.  My basic
bottom line is: 

(1) Section 9 has a lot of words and basically makes one new concrete
    suggestion (only responding to close out-of-window packets) over and
    above what has been specified and considered elsewhere.  That could
    be written in a two page I-D, but I guess somehow it feels better in
    some tour de force omnibus document?  Who knows ...

(2) You use the notion of "removal" a lot in your response.  It is
    inexplicable to me that this needs that much surgery to be
    acceptable after all this time.  Why are we being asked to review
    this if it is in such cruddy shape and you know it?  Why this big
    push to get even piece-meal reviewing done?  I mean, when you aren't
    even current to a Draft Standard on TCP congestion control that has
    been on the books for 18 months how are we supposed to take this
    seriously?  When you discuss blind attacks and don't even *mention*
    TCP-AO how are we supposed to take this seriously?

(3) Updating 18 documents with one document is a recipe for disaster.  I
    wonder---but not enough to go back and look---how the WG ever agreed
    to such a path.  I have seen enough on the list and off to have a
    pretty good idea that this thing has no consensus now and dollars to
    donuts it will never reach that bar.  We should not throw good
    effort after bad and move on to other items.  If there are useful
    bits in here they should be incorporated in the standards as
    necessary via the usual procedure and not via some massive catch
    all. 

allman