Subject: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-01.txt

From: [email-masked]
Date: Sun, 14 Jul 2013 15:34:39 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF.

	Title           : BGP operations and security
	Author(s)       : Jerome Durand
                          Ivan Pepelnjak
                          Gert Doering
	Filename        : draft-ietf-opsec-bgp-security-01.txt
	Pages           : 26
	Date            : 2013-07-14

Abstract:
   BGP (Border Gateway Protocol) is the protocol almost exclusively used
   in the Internet to exchange routing information between network
   domains.  Due to this central nature, it's important to understand
   the security measures that can and should be deployed to prevent
   accidental or intentional routing disturbances.

   This document describes measures to protect the BGP sessions itself
   (like TTL, MD5, control plane filtering) and to better control the
   flow of routing information, using prefix filtering and
   automatization of prefix filters, max-prefix filtering, AS path
   filtering, route flap dampening and BGP community scrubbing.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-bgp-security-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 15 Jul 2013 22:14:07 +0000

This is true but there is another case not listed.

"Attacks on TCP sessions used by BGP (ex: sending spoofed TCP
   RST packets) could bring down the TCP session.  Following a
   successful ARP spoofing attack (or other similar Man-in-the-Middle
   attack), the attacker might even be able to inject packets into
   the TCP stream (routing attacks)."

The spoofed rst tested we did in our lab based on this paper "Slipping in the tcp window" by Paul A Watson documented is NOT just for resets.
What he documented was around resets and so where his tests but reset isn't magic it was just simpler.

I never implemented a injection attack with ack but in theory that works just as well. It might take a bit longer but it would work in theory.

The reset testing we did killed sessions within a minute all the time (we cheated a bit we knew the src and dst ports) but were guessing the ack value based on windows size.
So there is nothing magic about the rst element. It is just a bit easier to just send the resets and not try to do a prefix hijack or something like that.

This paragraph mentions MD5 but tcp-ao actually obsoletes rfc 2385 so you might want to change that example to another algorithm.
Having said that MD5 collisions require you know M to create M' as far as I know. So since the bad guy doesn't know your shared secret I would say md5 is still valid for bgp session security.
If the bad guy does know your shared secret then he doesn't have to create M' he can create an M that would be valid;)

"The drawback of TCP session protection is additional configuration
   and management overhead for authentication information (ex: MD5
   password) maintenance.  Protection of TCP sessions used by BGP is
   thus recommended when peerings are established over shared networks
   where spoofing can be done (like IXPs)."

Recommending MD5 to tcp-ao without strongly recommending TTL security with it is a bit dangerous.
The authors mention TTL security right below that but I think it should be recommended IF you implement either of those options.

"BGP sessions can be made harder to spoof with the TTL security [9].
   Instead of sending TCP packets with TTL value = 1, the routers send
   the TCP packets with TTL value = 255 and the receiver checks that the
   TTL value equals 255.  Since it's impossible to send an IP packet
   with TTL = 255 to a non-directly-connected IP host, BGP TTL security
   effectively prevents all spoofing attacks coming from third parties
   not directly connected to the same subnet as the BGP-speaking
   routers.  Network administrators SHOULD implement TTL security on
   directly connected BGP peerings."

In many modern routers the ttl is decremented by the line card before the packet is sent up the "stack" so I believe in most cases the "router" will see a ttl of 254.
Some routers do NOT have an initial TTL of 255. Having a default initial TTL of 255 should be strongly recommended in the TTL section (all routers heck everything should have an initial of 255 we could do a lot more antispoofing work if they did).
TTL security should be changed to GTSM. That is what is referenced at the bottom and the correct term:)

The rest looked good to me.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]

From: [email-masked] [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Sunday, July 14, 2013 4:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-01.txt

Abstract:

_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: Matsuzaki Yoshinobu <[email-masked]>
Date: Tue, 30 Jul 2013 22:05:15 +0900 (JST)

Some comments about the prefix filtering to clarify use cases.

As an AS operator, I always care about 1. bgp neighbor IP and 2. bgp
nexthop (and routes used by bgp recursive route lookup) to protect our
routing.

For iBGP, "5.1.4. Filtering prefixes belonging to local AS" works
well.  Regarding eBGP, we peers with other ASes over IXPs and also
private links.  The IXP case is well documented at "5.1.5. Internet
exchange point (IXP) LAN prefixes", but we also need to care about the
private link prefixes, as sometimes these prefixes are assigned by
peering partners.

As we usually assign /30(IPv4) and /64, /126 or /127(IPv6) for those
private links, we are protecting our network from unintended routing
by denying too specifics described at "5.1.3.  Prefixes too specific".

Regards,
-----
Matsuzaki Yoshinobu <[email-masked]>
 - IIJ/AS2497  INOC-DBA: 2497*629

[email-masked] wrote

---

From: Jacques Latour <[email-masked]>
Date: Tue, 30 Jul 2013 12:11:44 -0400

Page 24 - incorrect reference

[34]       , "IANA IPv4 Special Purpose Address Registry", , <http://
              www.iana.org/assignments/iana-ipv6-special-registry/iana-
              ipv6-special-registry.xml>.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Matsuzaki Yoshinobu
> Sent: July-30-13 9:05 AM
> To: [email-masked]
> Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-01.txt
> 
> As an AS operator, I always care about 1. bgp neighbor IP and 2. bgp nexthop
> (and routes used by bgp recursive route lookup) to protect our routing.
> 
> For iBGP, "5.1.4. Filtering prefixes belonging to local AS" works well.  Regarding
> eBGP, we peers with other ASes over IXPs and also private links.  The IXP case is
> well documented at "5.1.5. Internet exchange point (IXP) LAN prefixes", but we
> also need to care about the private link prefixes, as sometimes these prefixes
> are assigned by peering partners.
> 
> As we usually assign /30(IPv4) and /64, /126 or /127(IPv6) for those private
> links, we are protecting our network from unintended routing by denying too
> specifics described at "5.1.3.  Prefixes too specific".
> 
> Regards,
> -----
> >  This draft is a work item of the Operational Security Capabilities for IP
> Network Infrastructure Working Group of the IETF.
> >