Internet2 Network Security SIG

[Andrew Gallo <>]

Reviving a bit of an old thread here....

We're a Juniper shop, and I was a bit jealous of how easy it was to configure 
GTSM on the other platforms.  So, I wrote a commit script to configure GTSM 
on a per-peer basis:

https://github.com/CAAREN-engineering/JCommit/blob/master/GTSM.slax

The script looks for a tag (apply-macro GTSM) in each BGP peer, and if it 
finds it, puts all the neighbor addresses in a prefix-list.
The script assumes that there is a term in a firewall filter that uses this 
prefix list to implement the filtering.

I haven't yet used this is production, but at some point, I'll schedule an 
outage to configure GTSM between our regional and our campus network and use 
this script to implement the change.

Any comments, questions- always welcome.

Thank you.



On 1/27/2017 1:18 PM, gcbrowni wrote:
> I went ahead and write up another topic, GTSM, at 
> https://spaces.internet2.edu/display/RS/GTSM 
> <https://spaces.internet2.edu/display/RS/GTSM>
>
> There’s some ambuiguity with the Brocade command. I’m inquiring to get mroe 
> information.
>
> As always, and input or feedback is appreciated! Especially on modern 
> configurations for the three vendors...
>
>
>
>
>
>
>
> GTSM
> Section 5.2 of RFC 7454 discusses BGP TTL filtering, otherwise known as the 
> Generalized TTL Security Mechanism, GTSM.
>
> The concept uses the TTL value in TCP packets to provide a quite strong 
> mechanism to prevent spoofed packets from being accepted. When a packet 
> passes through the router the router decrements the TTL value by one. If your 
> directly connected BGP neighbor explicitly sets the TTL on their outgoing BGP 
> packets to 255 then you can check all packets from that neighbor to ensure 
> they equal 255. If the TTL value is less than 255 then you know the packet is 
> spoofed; it has passed through at least one router, which has decremented the 
> TTL value.
> Since the TTL field is 8-bits, and 255 is therefore the maximum, sessions 
> using GTSM set their values to 255 and check to ensure that their adjacent 
> neighbors BGP session packets have a value of 255, throwing out all others 
> with a lower value from that neighbor. This is a very powerful mechanism that 
> uses the default behaviour of the routers interacting with the TTL field to 
> ensure spoofed packets can’t reach your session from more than one hop away … 
> at least for those neighbors that have it configured.
> There are some things to watch out for …
> First, GTSM needs to be configured on both sides of the BGP session, on a per 
> BGP session basis. You need to set your TTL to 255 and you need to check to 
> ensure that your neighbor s BGP packets have 255 TTL when you receive them. 
> And your neighbor needs to ensure the same thing. At a minimum to you need to 
> coordinate the setting of the TTL to 255 with them.
> Second, a TTL of 255 is not always correct. If your neighbor is not directly 
> connected/you’re doing multi-hop BGP, then the TTL value will be something 
> other than 255. You and your neighbor will need to coordinate on the 
> appropriate value to check for. (Although, you WILL be setting your TTL to 
> 255 regardless of how many hops away they are.) The drawback, of course, is 
> that you are now more vulnerable to spoofing from that connection. As the RF 
> notes “anyone inside the TTL diameter could spoof the TTL.”
>
> Juniper Example
> Junipers implementation is a bit cumbersome, relying on setting up a filter 
> with the “ttl-except” keyword and applying that filter on the appropriate 
> interfaces.
> filter ttl-security {
>   term gtsm {
>    from {
>     source-address {
>      10.1.2.3/32; }
>     protocol tcp;
>     ttl-except 255;
>     port 179; }
>    then {
>     discard; }}
>   term else {
>    then {
>     Accept;
>
> There’s more information on the  ttl mechanism on the Juniper site at:
> https://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/ttl-edit-protocols-bgp-mulithop.html
>  
> <https://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/ttl-edit-protocols-bgp-mulithop.html>
>
>
> Cisco Example
> Cisco BGP configurations support the “ttl” option, meaning it’s quite easy to 
> configure GTSM. The following example uses groups, but you can also use the 
> neighbor statement “ttl-security hops 1”
> bgp {
>   group toAS2 {
>    type external;
>    peer-as 2;
>    ttl 255;
>    neighbor 10.1.2.3;
>
> There a decent set of document about this feature on Cisco’s site at:
> https://supportforums.cisco.com/document/86776/securing-ebgp-sessions-ttl-security-feature
>  
> <https://supportforums.cisco.com/document/86776/securing-ebgp-sessions-ttl-security-feature>
>
> Brocade Example
> Brocade supports GTM with the “ebgp-btsh” bgp neighbor command. This works 
> with a TTL for 255/254, but it’s unclear if other TTL’s can be supported.
> neighbor 10.10.10.1 remote-as 2
> neighbor 10.10.10.1 ebgp-btsh
>
> There’s Brocade documentation to explain the command further at:
> http://www.brocade.com/content/html/en/command-reference-guide/FI_08030_CMDREF/GUID-20AF9E52-5746-4D0D-8871-663F15EFE4F7.html
>  
> <http://www.brocade.com/content/html/en/command-reference-guide/FI_08030_CMDREF/GUID-20AF9E52-5746-4D0D-8871-663F15EFE4F7.html>

--
________________________________
Andrew Gallo
The George Washington University

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature