Subject: Re: Issue 19) Security Considerations

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 May 2003 11:08:04 -0400

In message <[email-masked]>, "Joris Dobbelsteen" 
writes:
> Curtis, it was not my intension to upset you in any way. Still it looks
> like I successed doing that....... Any way, we do need some feedback
> from practical deployments.

I intended to respond to this message after clearing a few things up,
but it got deferred for much longer than it should have.  No offense
taken.  None intended either.

> My personal consideration would be not to put it in a chapter 4.2 but
> get it throughout the entire draft.

That would be fine.

> Packet filters provide the good protection for IBGP sessions. These are
> harder/impractical for EBGP(?).
> Internal attacks and hacks on the network channels are not considered
> practical.

The reason that packet filters are hard to get deployed on EBGP is the
attack can come from your peer and you have no control over your
peer's router, except to request that filters be put in place.

If an internal router is compromised there are many attacks possible
in addition to BGP.  The same applies to an internal compromise to
other critical infrastructure machines such as NMS.

> IPSec is not recommended because at least three reasons:
> TCP-MD5 is already widely implemented and deployed.
> Complication in network management, because packet filters need to be
> adapted for IPSec traffic (port 500 - IKE).
> IPSec has higher processing demands that TCP-MD5 does, lowing the
> barrier for a successful DoS attack. Hardware IPSec implementations are
> considered impractical, due to the cost or performance.
> 
> This brings up your statement that IPSec covers the ports. This is not
> true, when encryption (ESP) is not used. The use of intigrity (AH)
> will not hide the ports, it works sorta TCP-MD5, if you want...
> I also did never consider using ESP, since it was not desired and it
> would be the way to 'promote' DoS attacks.
> Unfortunally I don't have any insight on IPSec hardware, maybe some else
> can give some insight on this.
> 
> I suppose this closes the IPSec/TCP-MD5 issue, leaving TCP-MD5 to the 
> current best option.

Use of AH is an option.  It offers little benefit over TCP-MD5.  It
would be better if there was a way for ESP to expose the ports.

> Still this leaves EBGP open for consideration.
> 
> The use of BGP TTL Security Hack (BTSH) might be a very simple and
> effective way of protecting the external routers from attacks,
> especially DoS attacks. Malicious data can be prevented using TCP-MD5.
> The disadvantage is that it is not deployed widely, but only requires
> routers to send there traffic with an initial TTL of 255. I don't
> know if this is currently possible to archieve: whether current
> implementations can be set to send with an initial TTL of 255. It is
> not needed for both end-points to support BTSH, although desired.
> <draft-gill-btsh-01.txt>

It is simple.  It is easy.  It works.  This TTL check can be done in
hardware in many (most?) routers.

Another mitigation of attack is to build routers such that the BGP TCP
(and optionally the whole Adj-In and much of the AdjOut handling) is
done on the line card, minimally the TCP-MD5 authentication.  Some
routers also include internal hardware queues that can be used for SFQ
handling of traffic to the line card from outside.  If an attack
occurs on an EBGP peer, the attack only affects peers served by that
line card and if SFQ is available may only affect that peer.  If so, a
peers that do not implement (or enable) filtering or BTSH affects only
their own connectivity.

> I couldn't find any information about dynamic 4-tuple filtering
> (google turns up BGP dynamic capabilities), unfortunally.

Vijay Gill gave a presentation at NANOG.  Once established a 4-tuple
filter (src/dst addr+port) is installed for a BGP peering giving that
traffic priority over other 4-tuples.  A DoS attack on the intigrity
check then impacts the ability to get to the established state but
does not impact established connections.

> So what else can be done to prevent a EBGP session from attacks,
> especially DoS attacks? Data insertion/manipulations can be guarded
> against using TCP-MD5 (or similar).

Traffic based DoS which overwhelms the intigrity check is the hardest
problem we currently face.  It is solved for IBGP by adequate
filtering and keeping the routers or other infrastructure machines
from being compromised.  BTSH solves it for EBGP unless the peer is
compromised.  Limiting the impact of a full bandwidth attack from a
peer is something that a limited set of routers may be capable of.

> - Joris

Sorry for the delay.  I deferred a response to this and then it got
lost/buried in my inbox.

Curtis

> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]On Behalf Of
> >Curtis Villamizar
> >Sent: Thursday, 3 April 2003 16:36
> >To: Joris Dobbelsteen
> >Cc: 'IDR WG (E-mail)'
> >Subject: Re: Issue 19) Security Considerations 
> >
> >In message <[email-masked]>, 
> >"Joris Dobbelsteen" 
> >writes:
> >> [snip]
> >
> >Joris,
> >
> >Quite frankly I'm outraged at such comments.  Only by looking at
> >theoretical security issues and ignoring reality (not that the two
> >don't highly but imperfectly overlap) can you come to the conclusion
> >that IPSEC is needed and in its current form is viable as a security
> >solution for BGP.
> >
> >I think its about time we injected some reality into
> >draft-murphy-bgp-vuln-02.txt.
> >
> >I've added a practical considerations section.  I stuck it in as 4.2.
> >
> >Comments are welcome, particularly comments from people actually
> >running BGP networks or building BGP routers used by ISPs.
> >
> >I did not mention advanced filtering works-in-progress or proposals
> >such as BTSH or dynamic 4-tuple EBGP filtering since these are not yet
> >implemented or deployed afaik.  [aside: I strongly believe that BTSH
> >will prove to be a viable to protect EBGP and a preferable replacement
> >for current filtering which some older TTM (time-to-market) line cards
> >still in use are unable to support.]
> >
> >I should also note that the filtering best practices are far from
> >universally deployed and in some cases are difficult to fully deploy
> >due to residual use of TTM line cards unable to support filtering.
> >
> >Note that IPSEC with port numbers exposed would be a viable security
> >solution.  It would still be a greater computational burden than
> >TCP-MD5 and still might be less preferred by ISPs for that reason for
> >some architectures.  This change to IPSEC would at least yield two
> >viable options and might encourage implementation and deployment of
> >IPSEC as a security solution for BGP.
> >
> >Curtis
> >
> >
> >--- draft-murphy-bgp-vuln-02.txt	Wed Mar  5 21:00:00 2003
> >+++ draft-murphy-bgp-vuln-02.txt++	Thu Apr  3 09:18:12 2003
> >@@ -149,6 +149,7 @@
> > 3.2.2.2 Timer events 
> >..............................................   16
> > 4 Security Considerations 
> >.........................................   16
> > 4.1 Residual Risk 
> >.................................................   16
> >+4.2 Practical Considerations 
> >......................................   16
> > 5 References 
> >......................................................   17
> > 6 Author's Address 
> >................................................   18
> > 
> >@@ -901,6 +902,79 @@
> > Filtering is in use near some customer attachment points, but is not
> > effective near the Internet center.  The other mechanisms are still
> > controversial and are not yet in common use.
> >+
> >+4.2 Practical Considerations
> >+
> >+The primary usage of BGP is as a means to provide reachability
> >+information to Autonomous Systems (AS) and to distribute external
> >+reachability internally within an AS.  BGP is the routing protocol
> >+used to distribute global routing information in the Internet.  BGP is
> >+therefore used by all major Internet Service Providers (ISP) and many
> >+smaller providers and other organizations.  
> >+
> >+The role which BGP plays in the Internet puts BGP implementations in
> >+unique conditions and places unique security requirements on BGP.  BGP
> >+is operated over interprovider interfaces in which traffic levels push
> >+the state of the art in specialized packet forwarding hardware and
> >+exceed the performace capabilities of hardware implementation of
> >+decryption by many decimal orders of magnitude.  
> >+
> >+ISP networks must be and are under tight control.  The only viable
> >+means to protect the network elements from Denial of Service (DoS)
> >+attacks under such conditions are packet based filtering techniques
> >+based on relatively simple inspections of packets.
> >+
> >+To protect Internal BGP (IBGP) sessions, filters are applied at all
> >+borders to an ISP network which remove all traffic destined for
> >+addresses of network elements internal addresses (typically contained
> >+within a single prefix) and the BGP port number (179).  Packets from
> >+within an ISP are not forwarded from an internal interface to the BGP
> >+speaker's address on which External BGP (EBGP) sessions are supported,
> >+or to a peer's EBGP address if the BGP port number is found.  With
> >+appropriate consideration in router design, in the event of failure of
> >+a BGP peer to provide the equivalent filtering the risk of compromise
> >+can be limited to the peering session on which filtering is not
> >+performed by the peer or the interface or line card on which the
> >+peering is supported.  There is substantial motivation and little
> >+effort for ISPs to maintain such filters.
> >+
> >+Being composed entirely of specialized network equipment, under strict
> >+control of the ISP, the ISP network is not subject to attacks from
> >+within than enterprise networks are with more generalized computing
> >+systems and staff less carefully trained in the area of secure
> >+procedures.  ...
> 
> For me personally, the above sentence is a little hard to understand.
> You mean that ???
> The Internal BGP routers (or specialized network equipment) that is under
> strict control of the ISP is not subject to attacks, other than those that
> are common in enterprise networks. These networks have staff that is
> less carefully trained in the area of security procedures.
> 
> >+ ...........  Monitoring of traffic from within requires either
> >+compromise of relatively physically secure and carefully administered
> >+network elements or monitoring physical media.  Injection of traffic
> >+requires either compromise of network elements or intercept and
> >+replacement of traffic on physical media.
> >+
> >+The difficulty of compromise of network elements and of undetected
> >+tapping into physical media carrying extremely high volumes of traffic
> >+is much greater than the difficulty of injecting sufficient traffic
> >+from outside a network to effect a DoS attack.  As a result, the
> >+ability to packet filter on the basis of port numbers far exceeds the
> >+need to cryptographic strength in encapsulation.
> >+
> >+These practical considerations yield the situation in which TCP-MD5,
> >+though cryptographic weak, far better serves ISP security needs than
> >+the cryptographicly much stronger IPSEC which makes packet filtering
> >+infeasible.
> >+
> >+Use of BGP in smaller networks yields similar requirements.  The
> >+capability of a single workstation with high speed interface to
> >+generate false traffic far exceeds the capability of software based
> >+decryption or appropriately priced cryptographic hardware.  From a
> >+practical standpoint, these networks are also better served by
> >+appropriate administrative care, filtering, and TCP-MD5 than by IPSEC.
> >+
> >+This situation is likely to persist unless either cryptographic
> >+hardware becomes many orders of magnitude faster and cheaper or IPSEC
> >+supports an ability to leave IP port numbers exposed.  This
> >+requirement has been made known to the IPSEC WG.
> >+
> 
> See above, using intigrity only (AH), leaves TCP (not IP) port numbers
> readable for everyone. This security is rather an IPSec configuration
> option.
> 
> >+Until such time as IPSEC is modified, there is little choice but to
> >+mandate TCP-MD5 implementation and recommend TCP-MD5 usage for BGP and
> >+discourage IPSEC usage for BGP.
> > 
> > 5.  References
> > 
> >
>