Subject: [RPSEC] Backbone attacks and protections (fwd)

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Apr 2006 20:28:06 +0300 (EEST)

Hi,

As there was some discussion of TCP-MD5 and revisions at the last SAAG 
meeting, I claimed on jabber that getting a TCP-MD5 replacement is not 
really such a critical thing, as TCP-MD5 itself has rather limited 
applicability (and attack vector).  I also promised to write an I-D.

Well, here's a short I-D which gives an overview of my operator 
perspective (inputs from a couple of others have been incorporated) of 
main threats to backbone routers and their routing protocols in 
particular.

Now would be a good time to read and comment, because I'm going to 
revise the doc in 2-3 weeks.

I suggest directing followups to either:
  1) rtgwg list ([email-masked])
  2) saag list only
  3) myself only

---------- Forwarded message ----------
Date: Fri, 31 Mar 2006 23:27:29 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: Backbone attacks and protections (was: TCP-RST and GTSM)

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

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