Subject: [tcpm] feedcback on tcp-secure-05

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jul 2006 10:28:11 -0700

I had the following comments on v05.

Joe
--------

The doc continues to have a detailed but somewhat incomplete discussion
of the attack scenario; the point of tcp-antispoof was to provide a much
more detailed version of that discussion that should not be
recapitulated but rather cited.

The doc cites a *very* old version of tcp-antispoof, too.

No reasoning is given for numeric limits to ACK throttling (why 10 in 5
seconds? why not a ratio of the number of conventional ACKs provided)

TCP-MD5 isn't considered as a useful protection from these attacks (and
it is).

The use of both IPsec-AH and IPsec-ESP is suggested for on-path attacks,
where only one of the two is required.

The doc should also indicate that preventing these attacks does NOT
prevent ICMP attacks (and cite Gont's draft in this regard); it would be
useful for the security considerations to address whether ICMPs should
be blocked altogether and what the impact of that would be. Without such
blocking, it's not clear what the utility of this solution would be.

The middlebox considerations (sec 8.1) declare that some behavior is
noncompliant, but don't consider whether it already exists and how to
make their system avoid ACK wars that might result (e.g., to detect and
quench such a war, which seems separate from ACK throtling per se).

-----------------------------------------
THIS IS THE BIG POINT REGARDING REVISION:

The specific modifications suggested are given as loosely discussed
recipes rather than a specific list of the modifications to TCP; IMO,
the latter should be required.

-----------------------------------------

The blind data injection attack suggests that the window of
vulnerability can be as large as the amount of unacknowledged data,
which can be as large as the window. This means that even if the RST
attack is reduced from a fraction of the windowsize to 1, a similarly
detrimental attack can still occur from data injection. This needs to be
discussed in the security considerations, and continues to render the
utility of the RST protection of limited comparable value.

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Jul 2006 20:44:17 +0300 (EEST)

Note: I have not read the spec.  I'd intend to do it once it gets into 
WGLC.  But some follow-up to some of Joe's points below,

> recapitulated but rather cited.

You couldn't just simply cite it without any summary though, as 
antispoof is heading Informational, and doing so would likely require 
a down-ref.

> seconds? why not a ratio of the number of conventional ACKs provided)

Simpler to implement, maybe?

> blocking, it's not clear what the utility of this solution would be.

First of all, your last comment is correct only in isolation, i.e., 
when ICMP attack protections have not been implemented but this is. 
In reality, all vendors have implemented ICMP attack protections for 
at least about 1.5 years.

I do no think this document should be saying anything about blocking 
ICMPs.  On the other hand, reference to ICMP attacks would probably 
make sense.  Whether there should be more extensive discussion of ICMP 
attacks might or might not make sense, depending on the how heavily 
this doc would depend on the security discussion of tcp-antispoof.

> the latter should be required.

I'd agree that specific modifications would likely be preferable.

In section 3.2 the text says:

    Instead, this document requires that implementations MUST perform the
    following steps in place of those specified in [RFC0793](listed
    above).

Just to be clear, I'd rather say:

    Instead, this document requires that implementations that
    implement this specification MUST perform the
    following steps in place of those specified in [RFC0793](listed
    above).

or something like that.  This doc is not making the behaviour of 793 
incompliant, surely.  But rather introducing a specification that, if 
implemented, must be done in a certain way.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jul 2006 10:51:45 -0700

Pekka Savola wrote:
> antispoof is heading Informational, and doing so would likely require a
> down-ref.

It's not a down ref to cite an informational document informationally ;-)

> Simpler to implement, maybe?

Sure, a fixed number is simpler, but a reason for the specific numbers
would be useful too.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Jul 2006 20:57:47 +0300 (EEST)

> It's not a down ref to cite an informational document informationally ;-)

Sure.  But an Informative reference needs to refer to _additional_ 
information, not _replace_ information.  So, with an informative 
reference you will need to have at least short summary (a paragraph) 
of the issues.

---

From: Randall Stewart <[email-masked]>
Date: Thu, 13 Jul 2006 14:00:28 -0400

Pekka Savola wrote:
> reference you will need to have at least short summary (a paragraph) of 
> the issues.
> 
Yep.. we could say something like..

For further reference information on these refer to ....

Note to Joe, the older revision of anti-spoof comes right
from the xml database... not sure why it did not snarf
your latest version..

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jul 2006 11:05:48 -0700

> reference you will need to have at least short summary (a paragraph) of

Agreed, though we're talking about background and motivation, which
isn't as critical.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jul 2006 11:06:41 -0700

> from the xml database... not sure why it did not snarf

I don't use XML, so maybe they incorporate xml2rfc-based stuff more
quickly?

If not, it's _very_ out of date ;-)

Joe

---

From: Randall Stewart <[email-masked]>
Date: Thu, 13 Jul 2006 17:17:58 -0400

Joe Touch wrote:
> ------------------------------------------------------------------------
> 
We will look into it and fix whatever is wrong.. xml can
be funny at times.. and we could have some invalid tag..

R

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Jul 2006 14:30:39 -0700

The tag probably refers to the individual submission, and should be
updated to refer to the WG one. That's probably the disconnect ;-)

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 15 Jul 2006 16:27:00 -0300

>blocking, it's not clear what the utility of this solution would be.

I disagree with having the security considerations section of a 
document that does not focus on ICMP to basically propose to eliminate ICMP.

There's an entire document of this very same WG dicussing the 
relationship between ICMP and TCP.

Kindest regards,

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

---

From: Joe Touch <[email-masked]>
Date: Sun, 16 Jul 2006 22:00:21 -0700

Fernando Gont wrote:
> I disagree with having the security considerations section of a document
> that does not focus on ICMP to basically propose to eliminate ICMP.
> 

The ICMP document is a general document; this document (IMO) is more
about what to do when under suspected attack (or should be, to some extent).

If tcp-secure doesn't recommend blocking when tcp-secure is active
(i.e., when such attacks are suspected), then there is no point to the
rest of tcp-secure. It is useless to address the more challenging
spoofing attack vector and not address the easier one.

Joe

---

From: Ted Faber <[email-masked]>
Date: Mon, 17 Jul 2006 11:02:38 -0700

As a participant, not a chair.

On Sun, Jul 16, 2006 at 10:00:21PM -0700, Joe Touch wrote:
> The ICMP document is a general document; this document [tcpsecure
> --tvf]  (IMO) is more about what to do when under suspected attack (or
> should be, to some extent).

That's more broad a view of tcpsecure than the one I have.  It's a
mitigation of a specific attack vector, not a handbook for dealing with
off-path TCP attacks.  Personally I prefer to keep it more tightly
scoped so there's a chance of finishing it.

> spoofing attack vector and not address the easier one.

While I'm not opposed to adding text to that effect, I don't think it's
a requirement.  There are plenty of other possibilities for attack when
the tcpsecure code additions are exercised, and I don't see that this
document needs to address them all.  For that matter, the tcpsecure
document has never proposed a detection mechanism for those attacks.
All that is new work, and IMHO, well beyond the scope of the document
that the WG agreed to.  I'm happy to be convinced otherwise.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Ted Faber <[email-masked]>
Date: Tue, 18 Jul 2006 11:18:52 -0700

I've attached some text that I'd like to propose for the Security
Considerations secition of this draft in an effort to make its scope
clear and hopefully address some of Joe's concerns about ICMP.

This is just me, a participant, making the suggestion.

Text is attached.  Let me know what you think.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Jul 2006 21:27:00 +0300 (EEST)

> Text is attached.  Let me know what you think.

I'm having practical problems with the second paragraph (the rest 
looks OK).  It seems to imply that RFC 4301 adequately discusses the 
issues and is a useful starting point for developing a prevention 
policy _in practice_ (as very few sessions can use IPsec to prevent 
from ICMP attacks).  My belief is that both of these implications are 
incorrect.

On the other hand, I'd replace the text with references to 
tcpm-antispoof and tcpm-icmp-attacks which both go to some length in 
discussing this issue.  The former could be cited in the first 
paragraph, the latter provided as a main discussion of ICMP attacks in 
the second paragraph.

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Jul 2006 12:55:38 -0700

Pekka Savola wrote:
> I'm having practical problems with the second paragraph (the rest looks
> OK).  It seems to imply that RFC 4301 adequately discusses the issues
> and is a useful starting point for developing a prevention policy _in
> practice_ (as very few sessions can use IPsec to prevent from ICMP
> attacks).  My belief is that both of these implications are incorrect.

6.1.1 might be the more relevant particular section; it talks about
receipt of unprotected (un-IPsec'd) ICMPs.

> paragraph, the latter provided as a main discussion of ICMP attacks in

The other references might be useful, but pointing directly to 6.1.1 is
less indirect and more to the point about the tradeoff of protection vs.
responsiveness.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Jul 2006 16:20:29 -0300

>>clear and hopefully address some of Joe's concerns about ICMP.
[....]
>from ICMP attacks).  My belief is that both of these implications 
>are incorrect.
>
>paragraph, the latter provided as a main discussion of ICMP attacks 
>in the second paragraph.

FWIW, I second Pekka's opinion. (As a matter of fact, what to do even 
in the case of IPSec'ed conenctions, is, IMO, up to the 
interpretation of who reads the IPSec spec.)

Kindest regards,

---

From: Randall Stewart <[email-masked]>
Date: Tue, 18 Jul 2006 16:22:35 -0400

Ted/All:

With the minor tweak of pointing directly to
6.1.1 .. I think what you have proposed is
the right set of wording..

Getting bogged down in a ICMP attack issues disortation
is silly and detracts from what we are trying to do...
get tcp-secure finished...

We can have a food-fight over the ICMP attacks document
in the space of that document...

R

Ted Faber wrote:
> Implementors should be aware that the attacks detailed in this
> specification are not the only attacks available to an off-path attacker
> and that the countermeasures described herein are not a comprehensive
> defense against such attacks.
> 
> In particular, administrators should be aware that forged ICMP messages
> provide off-path attackers the opportunity to disrupt connections or
> degrade service.  Such attacks may be subject to even less scrutiny than
> the TCP attacks addressed here, especially in stacks not tuned for
> hostile environments.  Section 6.1 of RFC4301 describes the issues
> associated with unauthenticated ICMP messages, e.g., messages from an
> off-path attacker, and is a good starting point for formulating a policy
> on those messages.
> 
> In any case, this RFC details only part of a complete strategy to
> prevent off-path attackers from disrupting services that use TCP.
> Administrators and implementors should consider the other attack vectors
> and determine appropriate mitigations in securing their systems.
> 
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Jul 2006 12:57:34 -0700

> Text is attached.  Let me know what you think.

I'd say 6.1.1 is more relevant; 6.1 as a whole also addresses ICMPs from
inside protected boundaries, which is not applicable outside IPsec.

> and determine appropriate mitigations in securing their systems.

Modulo above, that looks fine to me.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Jul 2006 17:57:30 -0300

At 17:22 18/07/2006, Randall Stewart wrote:

>the right set of wording.

That document discusses ICMP in the context of IPSec'ed connections. 
If the connection is already secured by IPSec, you wouldn't bother 
about "in window" attacks.

>get tcp-secure finished...

Agreed. Given that the WG already has a document on this issue, it's 
probably better to provide a reference to that document, rather than 
trying to make recommendations from scratch.

>in the space of that document...

FWIW, I'd be interested in not having such a fight over any of the 
two documents. Both of them are WG documents, and I'm interested in 
having both of them finished. Both in the case of tcpsecure (at least 
wrt the SYN-based and RST-based attacks) and the ICMP attacks draft, 
the industry has already implemented the counter-measures.

Given that my opinion is already stated, I will focus on working on 
the drafts I still ahve to revise, and will refrain from adding 
anything else to this thread.

Kindest regards,

---

From: Ted Faber <[email-masked]>
Date: Tue, 18 Jul 2006 14:23:01 -0700

> >the right set of wording.

Yeah, I missed a "1". 6.1.1 is the section I wanted.
> about "in window" attacks.

It does, but 6.1.1 talks about unauthenticated ICMP messages, which is
exactly what the issue is here - there's no IPSec in play in this
document so *all* ICMP is unauthenticated.  With that understanding,
which I tried to get across in my text, I think the discussion of the
pros and cons of blocking ICMP is a pretty good primer to help people
understand what they're getting into.

The goal is to indicate that there are tradeoffs here, but that they're
outside the scope of tcpsecure.

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Jul 2006 14:24:47 -0700

Fernando Gont wrote:
> That document discusses ICMP in the context of IPSec'ed connections. If
> the connection is already secured by IPSec, you wouldn't bother about
> "in window" attacks.

Sec 6.1.1 discusses handling untrusted ICMPs. In a non-IPsec
environment, all ICMPs fall into this category.

Joe

---

From: Ted Faber <[email-masked]>
Date: Tue, 18 Jul 2006 14:32:25 -0700

> from ICMP attacks).  My belief is that both of these implications are 

I don't get that from my text, and it's certainly not my intended
meaning.  The section (6.1.1, which si the one I should have pointed at)
nicely describes how different classes of ICMP can help or hurt you and
the tradeoffs of accepting them.

The point of my text is that even if you implement tcpsecure, you're not
done.  You've got other worries from off-path attackers and ICMP is one
of the big ones.  I said it's a starting point, and I don't think it's
more than that.  I also don't think it's worth trying to solve that
problem in this document, just point out to people securing their
machines that they're not done yet.

> paragraph, the latter provided as a main discussion of ICMP attacks in 

Anti-spoof should be referenced earlier on in the draft and I don't see
the benefit of an additional reference here.  If you'd like to provide
edited text with the reference you want in it, feel free, though.

I don't want to link this draft to icmp-attacks in a way that would slow
this draft's publication.  I think the ICMP issues are completely
ancillary to this document.  I think that noting that they exist is
sufficient.  In fact, I'm perfectly willing to delete the reference to
4301 and just say that while ICMP port unreachables can close
connections, ICMP fragmentation required can keep your packets
reasonably sized to go through the network.  If you'd like that text
polished, I can do it.

Alternatively, I'm sure text containing the references you think are
appropriate would be taken by the authors.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Jul 2006 20:32:01 -0300

At 18:23 18/07/2006, Ted Faber wrote:

>document so *all* ICMP is unauthenticated.

Section 6 says:
"   This section describes IPsec handling of ICMP traffic.  There are two
    categories of ICMP traffic: error messages (e.g., type = destination
    unreachable) and non-error messages (e.g., type = echo).  This
    section applies exclusively to error messages."

And Section 6.1 (parent of Section 6.1.1 and Section 6.1.2) is 
entitled "Processing ICMP Error Messages Directed to an IPsec Implementation"

I think this makes it perfectly clear that Section 6.1.1 is about 
unprotected ICMP messages *directed* to an *IPSec* implementation.

FWIW, Section 5.2 ("Processing Inbound IP Traffic 
(unprotected-to-protected)") of RFC 4301 says:
"   3c. Processing of ICMP messages is assumed to take place on the
        unprotected side of the IPsec boundary.  Unprotected ICMP
        messages are examined and local policy is applied to determine
        whether to accept or reject these messages and, if accepted, what
        action to take as a result.  For example, if an ICMP unreachable
        message is received, the implementation must decide whether to
        act on it, reject it, or act on it with constraints. (See Section
        6.)"

RFC 4301 never states that ICMP messages should be filtered. And its 
clear from this last paragraph that a number of behaviours (including 
"act on it with constraints") are among the possibilities.

I don't want to slow tcpsecure, nor any other draft (as a matter of 
fact, I didn't raise the ICMP issue). Issue raised, I think it's 
appropriate to state that tcpsecure does not prevent ICMP attacks. 
And being that the WG has a document on that issue, it would make 
sense to reference it.

It could something as simple as "This RFC does not prevent the ICMP 
based attacks discussed in [ICMP-Attacks]", where "ICMP-Attacks" is a 
reference to draft-ietf-tcpm-icmp-attacks.

That said, I think that all this provides a hint that the ICMP issues 
should be fixed on Standards track. However, I have no intention on 
spending cycles to change the path of the ICMP attacks drafts. I 
raised the question in a separate e-mail, and, IIRC, there were 
others that stated they would be glad to actually modify the specs.

Kindest regards,

---

From: Ted Faber <[email-masked]>
Date: Tue, 18 Jul 2006 17:07:28 -0700

> "act on it with constraints") are among the possibilities.

Fine.  Try the attached.

I'm happy to add an explicit reference to the attacks draft if it can be
phrased in such a way that it does not link the publication of the two.
Feel free to send text.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Jul 2006 21:37:28 -0300

>phrased in such a way that it does not link the publication of the two.

I'd change the text to:

"Implementors should be aware that the attacks detailed in this
specification are not the only attacks available to an off-path attacker
and that the countermeasures described herein are not a comprehensive
defense against such attacks.

In particular, administrators should be aware that forged ICMP messages
provide off-path attackers the opportunity to disrupt connections or
degrade service.  Such packets may be subject to even less scrutiny than
those required for the TCP attacks addressed here, especially in 
stacks not tuned for
hostile environments.

This RFC details only part of a complete strategy to
prevent off-path attackers from disrupting services that use TCP.
Administrators and implementors should consider the other attack vectors
and determine appropriate mitigations in securing their systems.

[antispoof] provides a detailed discussion of TCP attacks based on 
forged TCP segments, along with
a discussion on the possible counter-measures.  [ICMP-attacks] 
provides a detailed discussion on TCP attacks based
on forged ICMP packets, along with the possible counter-measures."

Note that I basically removed text, and added references. And that 
the references are included in a way in which there's no "requirement".

Kindest regards,

---

From: Ted Faber <[email-masked]>
Date: Tue, 18 Jul 2006 17:58:12 -0700

> the references are included in a way in which there's no "requirement".

As long as neither of those refs imposes dependencies on tcpsecure, I'm
delighted with the text.