Subject: Backbone attacks and protections (was: TCP-RST and GTSM)

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Mar 2006 23:27:29 +0300 (EEST)

Hi,

At IETF65, I raised the TCP-RST attack issue in GTSM, and Alex asked 
that I should talk with DaveM about it, work it out, and produce a 
draft.

Well, I did.. and soon figured out I'll need to write a more generic 
but concise draft first on what I believe are the main attack vectors 
against routing protocols running on backbone networks today, so that 
we can balance the risks.

Feedback is appreciated -- read it, it's only about 10 pages.  I'll 
also send a pointer to RPsec and SAAG a bit later, because there has 
been some discussion on TCP-MD5 replacements there.

http://www.ietf.org/internet-drafts/draft-savola-rtgwg-backbone-attacks-00.txt

Abstract

    A number of protection mechanisms for attacks against service
    provider backbone network infrastructure have been specified or
    proposed, each of them usually targeting a subset of the problem
    space.  There has never been a more generic analysis of the actual
    problems, and which protection techniques are even necessary (and
    where).  This document tries to provide that higher-level view.

... Oh, if you're interested, below is what I suggest we do with GTSM 
(though I'm very much open to discussion about this -- the attack 
loses most of its usefulness especially if the router already 
implements the draft-ietf-tcpm-tcpsecure hack..):

    The open issue at the moment is how GTSM handles TCP RSTs.  I.e.,
    should it require that RSTs for a GTSM-enabled session should be sent
    with TTL=255 and verified to come with TTL=255 (or a configured
    value)?  Do implementations already do this?  Is there a sensible
    transition plan or need to make a change if any?  Note that this has
    only limited impact on GTSM's security as other TCP RST mitigation
    techniques still apply.

    We suggest that the GTSM spec is amended that TCP RSTs relating to to
    a GTSM-enabled protocol port MUST be sent with TTL=255.  (Note that
    this will require a kernel modification, and a means to specify to
    the kernel which ports relate to GTSM.).  The recipients behaviour
    SHOULD be configurable, and it is RECOMMENDED that the default be to
    discard messages where TTL is not 255 (or 255-TrustRadius).

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

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

---

From: David Meyer <[email-masked]>
Date: Fri, 31 Mar 2006 15:50:02 -0800

>    discard messages where TTL is not 255 (or 255-TrustRadius).

	I think it might also be worthwhile thinking about
	discarding multi-hop GSTM, or at least surveying as to
	whether multi-hop is in use (since it so severely limits
	the coverage of the technique).

	Dave