[email protected]
[Top] [All Lists]

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

Subject: Backbone attacks and protections was: TCP-RST and GTSM
From: Pekka Savola
Date: Fri, 31 Mar 2006 23:27:29 +0300 EEST

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.


   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 protected]

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