[GTER] bgp ttl security -
rodrigo at 1telecom.com.br
Thu Dec 4 14:23:06 -02 2014
Estava lendo um material sobre outra coisa e me apareceu este aqui sobre BGP
ttl security em um site da cisco:
BGP Time To Live Security Check
Another BGP attack scenario that is listed at the beginning of this document
is a Denial of Service (DoS) attack against the BGP process. The BGP Time To
Live (TTL) security check is designed to protect the BGP process from these
kinds of CPU-utilization-based attacks and route manipulation attempts. The
BGP protocol must be examined in greater detail to understand how this
protection technique works.
The BGP protocol defines two types of sessions: internal BGP sessions
(iBGP), which are established between peers within the same Autonomous
System (AS), and external BGP sessions (eBGP), which are established between
peers in two different ASs. eBGP sessions are the BGP sessions that are
established between an Enterprise and its upstream SP.
By default and per the RFC, when eBGP is configured, the IP header TTL for
all neighbor session packets is set to 1. This setting was originally
assumed to be useful because it prevents the establishment of an eBGP
session beyond a single hop. However, an attacker could be located up to 255
hops away and still send spoofed packets to the BGP-speaking router
successfully. For example, an attacker could send large amounts of TCP SYN
packets to the BGP peer in hopes of overwhelming the BGP process. The BGP
MD5 neighbor authentication technique described earlier in this document
does not protect against this kind of attack and can actually exacerbate its
effects by causing the router CPU to expend resources while it attempts to
compute MD5 hashes on large numbers of attack packets. Therefore, another
mechanism was required to defend against BGP DoS attacks. The BGP TTL check
uses a clever modification to the original BGP RFC to accomplish this goal.
The BGP TTL security check leverages the fact that the vast majority of
Internet SP eBGP peering sessions are established between routers that are
adjacent to each other (for example, either between directly connected
interfaces or possibly between loopbacks). Because successful TTL spoofing
is considered nearly impossible, a mechanism that is based on an expected
TTL value was developed to provide a simple, robust defense from
infrastructure attacks that are based on forged BGP packets. The concept was
originally defined and subsequently modified in the following documents: BGP
TTL Security Hack (BTSH)
<http://smakd.potaroo.net/ietf/idref/draft-gill-btsh/index.html> and BGP in
The Generalized TTL Security Mechanism (GTSM)
When the BGP TTL security check is enabled, the initial TTL value for an
eBGP packet is set to 255 rather than 1, and a "minimum TTL-value" is
enforced on all BGP packets that are associated with that eBGP session.
Because the IP header TTL value is decremented by each router hop along its
path to its final destination, the diameter from which an attacker could
possibly source packets is restricted to those routers that are directly
The BGP TTL security check is not required nor is it considered useful for
iBGP sessions. The BGP TTL security check was first introduced in Cisco IOS
Software Releases 12.0(27)S, 12.3(7)T, and 12.2(25)S.
Refer to BGP Support for TTL Security Check
> for more information.
Minha dúvida é: se multihop nao está ativo significa que posso estabelecer
BGP atraves de rota conectada apenasaté entao ok, entao como a definicao de
ttl descrita me protegeria de spoofing por exemplo?
Ou somente habilitar ttl em conexoes multihop ? Ele ainda fala que
autenticacoes md5 nao protegem neste caso, e sim elevam o uso de cpu em caso
de ataques. É fato, uma vez que vai ficar verificando a hora toda a
Em minhas regras e firewall existe tambem que aceito conexoes bgp nos ip¹s
apenas dos BGP PEERS e tem um prefix-list criando um apply-path onde listo
estes ip¹s de forma automática.
Se correr o bicho pega e se ficar o bicho come?
PS> aqui nao uso ciscojuniper
Alguém poderia dar um briefing sobre o assunto por favor?
Gestor de T.I. Grupo Connectoway
* rodrigo at connectoway.com.br <mailto:rodrigo at connectoway.com.br>
( (81) 3497-6060
( (81) 8184-3646
( INOC-DBA 52965*100
More information about the gter