Subject: [tcpm] tcpsecure recommendations

From: Mark Allman <[email-masked]>
Date: Wed, 06 Feb 2008 12:40:17 -0500

Folks-

It'd be good to get some opinions on the new tcpsecure version and get
it finished.  The sticking point on this document is how strongly to
recommend TCP stacks implement / use the three mitigations in the draft
(to spoofed RSTs, SYNs and data segments).  We had a discussion about
this in Chicago and also on the list.  Since it seemed that we were not
converging because there was not WG-wide agreement on the scope of the
document we asked the authors to generate an applicability statement.
They did that, per a previous email from Anantha.  The AS reads:

    The mitigations presented in this document talks about some known
    in-window attacks and the solutions to the same. The mitigations
    suggested in this draft SHOULD (RECOMMENDED) be implemented in
    devices where the TCP connections are most vulnerable to the attacks
    described in this document.  Some examples of such TCP connections
    are the ones that tend to be long-lived where the connection end
    points can be determined, in cases where no auxiliary anti-spoofing
    protection mechanisms like TCP MD5 can be deployed. TCP secure MAY
    (OPTIONAL) be implemented in other cases.

We can recommend each of mitigations with a MAY, SHOULD or MUST.  In
Chicago we winnowed the proposals to three three:

    (1) RST spoofing mitigation: MAY
        SYN spoofing mitigation: MAY
        data injection mitigation: MAY

    (2) RST spoofing mitigation: SHOULD
        SYN spoofing mitigation: SHOULD
        data injection mitigation: SHOULD

    (3) RST spoofing mitigation: SHOULD
        SYN spoofing mitigation: SHOULD
        data injection mitigation: MAY

Nobody has advocated for other permutations of recommendations
(although, clearly if people like some different combination they should
advocate away!).  

Can folks please weigh in on their feeling about how strongly we should
recommend these mitigations given the AS above?  It'd be great to get
this document moving and we're sort of stuck here.

Thanks,
allman

_______________________________________________
tcpm mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/tcpm

---

From: David Borman <[email-masked]>
Date: Wed, 6 Feb 2008 12:42:22 -0600

I think the applicability statement is a great addition.  I'm in favor  
of (3), SHOULD/SHOULD/MAY.
			-David Borman

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 6 Feb 2008 10:50:22 -0800

I think it would be help if folks can also narrate the reason for
chosing a particular permutation.

My few cents,

-Anantha 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David Borman
> Sent: Wednesday, February 06, 2008 10:42 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [tcpm] tcpsecure recommendations
> 
> I think the applicability statement is a great addition.  I'm 
> in favor of (3), SHOULD/SHOULD/MAY.
> 			-David Borman
> 
> > recommend TCP stacks implement / use the three mitigations in the 
> > draft (to spoofed RSTs, SYNs and data segments).  We had a 
> discussion 
> > about this in Chicago and also on the list.  Since it 
> seemed that we 
> > were not converging because there was not WG-wide agreement on the 
> > scope of the document we asked the authors to generate an 
> > applicability statement.
> > (although, clearly if people like some different combination they 
> > should advocate away!).
> >
> > Can folks please weigh in on their feeling about how strongly we 
> > should recommend these mitigations given the AS above?  
> It'd be great 
> > to get this document moving and we're sort of stuck here.
> >
> > Thanks,
> > allman
> >
> >
> >

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 Feb 2008 07:52:29 -0800

Given the AS's statement below:
|     ... TCP secure MAY
|     (OPTIONAL) be implemented in other cases.
|
| We can recommend each of mitigations with a MAY, SHOULD or MUST.  In
| Chicago we winnowed the proposals to three three:

#3 makes most sense tm oe. #1 weakens the AS statement too much, and #2
covers data plane protection that there are too many other ways to spoof
(overwriting segments, or just writing segments with predicted header
data). This appears to be best applied to an unauthenticated control plane.

Joe

|     (1) RST spoofing mitigation: MAY
|         SYN spoofing mitigation: MAY
|         data injection mitigation: MAY
|
|     (2) RST spoofing mitigation: SHOULD
|         SYN spoofing mitigation: SHOULD
|         data injection mitigation: SHOULD
|
|     (3) RST spoofing mitigation: SHOULD
|         SYN spoofing mitigation: SHOULD
|         data injection mitigation: MAY
|
| Nobody has advocated for other permutations of recommendations
| (although, clearly if people like some different combination they should
| advocate away!).
|
| Can folks please weigh in on their feeling about how strongly we should
| recommend these mitigations given the AS above?  It'd be great to get
| this document moving and we're sort of stuck here.
|
| Thanks,
| allman
|
|
|
|
|
| ------------------------------------------------------------------------
|
| _______________________________________________
| tcpm mailing list
| [email-masked]
| http://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/tcpm

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sat, 9 Feb 2008 20:08:01 -0800

> 
> #3 makes most sense tm oe. #1 weakens the AS statement too 
> much, and 
> #2 covers data plane protection that there are too 
> many other ways to spoof (overwriting segments, or just 
> writing segments with predicted header data). This appears to 
> be best applied to an unauthenticated control plane.

I am assuming you are characterizing the reception of certain segments
like SYN/RST/FIN as control plane and pure data as otherwise?. Pl note
that tcp-secure mainly talks about injecting a bad segment which
eventually results in tearing down an established TCP connection. In
other words, I can't understand your reasoning for not going with #2.
What do you think are the issues going with #2 ?

Can you elaborate?

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Sun, 10 Feb 2008 09:44:45 -0800

Anantha Ramaiah (ananth) wrote:
|> #3 makes most sense tm oe. #1 weakens the AS statement too
|> much, and
|> #2 covers data plane protection that there are too
|> many other ways to spoof (overwriting segments, or just
|> writing segments with predicted header data). This appears to
|> be best applied to an unauthenticated control plane.
|
| I am assuming you are characterizing the reception of certain segments
| like SYN/RST/FIN as control plane and pure data as otherwise?. Pl note
| that tcp-secure mainly talks about injecting a bad segment which
| eventually results in tearing down an established TCP connection. In
| other words, I can't understand your reasoning for not going with #2.
| What do you think are the issues going with #2 ?
|
| Can you elaborate?

The key issues are:

- - lack of protection against injected data itself (I'm not sure if the
doc actually calls this out specifically; it probably should in the
security considerations section - even an off-path attacker can do this,
e.g.)

- - the word "eventually" above

IMO, if you are running a TCP connection that is susceptible to attacks
only by a *stream* of forged segments, you probably ought to use
something besides TCP-secure as protection.

As a result, I think that you SHOULD protect the control plane (if you
employ this technique), but that protection of attacks via data plane
volume are not as critical, and thus a MAY.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 10 Feb 2008 11:37:53 -0800

> 
> The key issues are:
> 
> - - lack of protection against injected data itself (I'm not 
> sure if the doc actually calls this out specifically; it 
> probably should in the security considerations section - even 
> an off-path attacker can do this,
> e.g.)

There are references to IPsec and MD5 etc., in the security section. I
think all the above is implied and understood. Like it has been
emphasised before many times, the purpose of TCP secure is to add
robustness to some cases and not to replace IPsec/MD5.

> IMO, if you are running a TCP connection that is susceptible 
> to attacks only by a *stream* of forged segments, you 
> probably ought to use something besides TCP-secure as protection.

Actaully it is not a "stream" of forged segments. A malicious segment
(which utilizes the liberal range of ACK value) can come and occupy any
place within the receive window, it could be in the re-assembly queue/or
somewhere inline, but this just like a "time-bomb' waiting to explode.
[The document mentions these possibilities under the data injection
section] Also as mentioned in the document FIN attacks are also possible
which is a control plane thingy ( using your terminology)

> 
> As a result, I think that you SHOULD protect the control 
> plane (if you employ this technique), but that protection of 
> attacks via data plane volume are not as critical, and thus a MAY.

Data injection is about strict ACK checking and applies to FIN segments.
To re-iterate: preventing anything which causes the connection tear down
maliciously is critical. So it could be a RST/SYN or Data or FIN.

But if your point is the mitigation should not be called as "data
injection" and something else, I agree. OTOH, the assumption is that any
implementer (true for any RFC) is going to read and understand that
tcp-secure provides adds robustness in some cases and for a
comprehensive data/control protection one is going to use MD5/Ipsec.
Like I pointed out earlier many times tcp-secure is not an
authentication mechanism and lot of folks agree to that, but you seem to
thinking this as an authentication mechanism and with that line of
thinking, your reasoning is fine, but the basic point is tcp-secure is
NOT a authentication mechanism, it is about protocol robustness :-) 

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Sun, 10 Feb 2008 14:58:58 -0800

Anantha Ramaiah (ananth) wrote:
...
| Actaully it is not a "stream" of forged segments. A malicious segment
| (which utilizes the liberal range of ACK value) can come and occupy any
| place within the receive window, it could be in the re-assembly queue/or
| somewhere inline, but this just like a "time-bomb' waiting to explode.

There are three issues listed in the ID:

"Blind reset attack using the RST bit"
"Blind reset attack using the SYN bit"
"Blind data injection attack"

The third one says "data corruption may result" - IMO, data corruption
is a possibility any time you don't use strict authentication, so it's
inaccurate to imply that if these checks are in place that data
corruption won't occur (which is what is implied, IMO).

The ACK war doesn't take down the connection. What takes down the
connection is that it accepted data it shouldn't have. IMO, the UTO
taking the connection down at this point is not as much an attack
succeeding, as it is TCP succeeding in not letting the attack go unnoticed.

Again, I don't see this case as needing a SHOULD. This is a data plane
issue, not, IMO, a control plane one.

...
| Data injection is about strict ACK checking and applies to FIN segments.
| To re-iterate: preventing anything which causes the connection tear down
| maliciously is critical. So it could be a RST/SYN or Data or FIN.

If preventing anything that could cause a malicious teardown is
critical, then use of strict authentication is required. Implications to
the contrary endorse the use of this "protocol robustness" mechanism for
true security (a misconception that the title doesn't help abate).

- ---

Also, FWIW, Section 9 doesn't appear to address the non-amplification
ACK exchange issue promised in the end of each of the previous sections.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 10 Feb 2008 15:25:36 -0800

> The third one says "data corruption may result" - IMO, data 
> corruption is a possibility any time you don't use strict 
> authentication, so it's inaccurate to imply that if these 
> checks are in place that data corruption won't occur (which 
> is what is implied, IMO).

"data corruption may result" because it is not the data what the
application intended to receive in the first place. Keeping the focus
intact, the liberal ACK allowed by the RFC has led to this condition
which otherwise would have been prevented. So data corruption can happen
in various places and various layers, we are simply talking about
plugging one hole which is in the jurisdiction of TCP.

> 
> The ACK war doesn't take down the connection. What takes down 
> the connection is that it accepted data it shouldn't have. 
> IMO, the UTO taking the connection down at this point is not 
> as much an attack succeeding, as it is TCP succeeding in not 
> letting the attack go unnoticed.

Agree that the connection might get torn down due to UTO/application
timeout, but why did this happen due to the liberal ACK range allowed.
Now this is what is being debated and the mitigation suggested. 

> 
> Again, I don't see this case as needing a SHOULD. This is a 
> data plane issue, not, IMO, a control plane one.

Data plane versus control plane, the distinction becomes blurry when FIN
comes into picture... Not sure how the data/control plane distinction is
made and why it is needed for determining the strength of the
mitigation. You haven't made this clear so far. 

> | To re-iterate: preventing anything which causes the connection tear 
> | down maliciously is critical. So it could be a RST/SYN or 
> Data or FIN.
> 
> If preventing anything that could cause a malicious teardown 
> is critical, then use of strict authentication is required. 
> Implications to the contrary endorse the use of this 
> "protocol robustness" mechanism for true security (a 
> misconception that the title doesn't help abate).

Agreed but again the above statement doesn't help in debate which we are
having, ie., the strength of the data mitigation. All so far I can
gather is that : somehow you are saying data mitigation is tied to "data
plane" and the rest are tied to control plane and hence in one case is a
SHOULD and the other a MAY. Sounds very dubious to me.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Sun, 10 Feb 2008 17:14:02 -0800

Anantha Ramaiah (ananth) wrote:
...
|> If preventing anything that could cause a malicious teardown
|> is critical, then use of strict authentication is required.
|> Implications to the contrary endorse the use of this
|> "protocol robustness" mechanism for true security (a
|> misconception that the title doesn't help abate).
|
| Agreed but again the above statement doesn't help in debate which we are
| having, ie., the strength of the data mitigation. All so far I can
| gather is that : somehow you are saying data mitigation is tied to "data
| plane" and the rest are tied to control plane and hence in one case is a
| SHOULD and the other a MAY. Sounds very dubious to me.

My comments are not intended to convince you to agree with me. I have
made my decision, and explained it, IMO.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 10 Feb 2008 18:24:00 -0800

> |> If preventing anything that could cause a malicious teardown is 
> |> critical, then use of strict authentication is required.
> |> Implications to the contrary endorse the use of this "protocol 
> |> robustness" mechanism for true security (a misconception that the 
> |> title doesn't help abate).
> |
> | Agreed but again the above statement doesn't help in debate 
> which we 
> | are having, ie., the strength of the data mitigation. All 
> so far I can 
> | gather is that : somehow you are saying data mitigation is tied to 
> | "data plane" and the rest are tied to control plane and 
> hence in one 
> | case is a SHOULD and the other a MAY. Sounds very dubious to me.
> 
> My comments are not intended to convince you to agree with 
> me. I have made my decision, and explained it, IMO.

Well, I was seeking clarification on the reasoning which you gave for
your choice! IMO, esp. after the AS is in place, it doesn't make sense
to color each individual mitigation differently.

-Anantha

---

From: Mark Allman <[email-masked]>
Date: Sun, 10 Feb 2008 22:54:41 -0500

Folks-

We do not need more unending debate on this subject.  We need to make a
collective decision about how strongly to recommend these mitigations.
I want to encourage folks to please poke their head up and voice their
opinion on this question (my original request is below for reference).
And, I would also like to ask folks to hold off on re-debating the
issues again.  Certainly, if you feel you have a *new* opinion to offer
or the AS has brought something *new and different* to the fore of your
thinking, by all means please raise the issue.

Thanks,
allman

Folks-

Thanks,
allman

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 18 Feb 2008 18:32:00 +0100

(2) my views are the same as last time.

Tom Petch

---

From: Mark Allman <[email-masked]>
Date: Mon, 18 Feb 2008 19:11:59 -0500

Folks-

Based on the minimal feedback in this thread and the hum we took in

>         data injection mitigation: MAY

The preference does not seem to be overwhelming, but in the absence of
additional input Ted and I are inclined to take the above option as the
WG's consensus.  Note, we do not see overwhelming preference here, but
we need to get this draft moving.  So, if you are opposed to this
approach and have not yet weighed in then now is your chance.  We know
that y'all will let us know if we have called this inappropriately.

Thanks!

allman
tcpm co-chair