[email protected]
[Top] [All Lists]

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

Subject: Re: Backbone attacks and protections was: TCP-RST and GTSM
From: David Meyer
Date: Fri, 31 Mar 2006 15:50:02 -0800
On Fri, Mar 31, 2006 at 11:27:29PM +0300, Pekka Savola wrote:
> 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).

        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).


Rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>