< draft-savola-rtgwg-backbone-attacks-01.txt   draft-savola-rtgwg-backbone-attacks-02.txt >
Routing Area WG P. Savola Routing Area WG P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Intended status: Informational June 13, 2006 Intended status: Informational July 12, 2006
Expires: December 15, 2006 Expires: January 13, 2007
Backbone Infrastructure Attacks and Protections Backbone Infrastructure Attacks and Protections
draft-savola-rtgwg-backbone-attacks-01.txt draft-savola-rtgwg-backbone-attacks-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 15, 2006. This Internet-Draft will expire on January 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
A number of countermeasures for attacks against service provider A number of countermeasures for attacks against service provider
backbone network infrastructure have been specified or proposed, each backbone network infrastructure have been specified or proposed, each
of them usually targeting a subset of the problem space. There has of them usually targeting a subset of the problem space. There has
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4
2. Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Lower-layer Attacks . . . . . . . . . . . . . . . . . . . 5 2.1. Lower-layer Attacks . . . . . . . . . . . . . . . . . . . 5
2.2. Generic DoS on the Router . . . . . . . . . . . . . . . . 5 2.2. Generic DoS on the Router . . . . . . . . . . . . . . . . 5
2.3. Generic DoS on a Link . . . . . . . . . . . . . . . . . . 5 2.3. Generic DoS on a Link . . . . . . . . . . . . . . . . . . 6
2.4. Cryptographic Exhaustion Attacks . . . . . . . . . . . . . 6 2.4. Cryptographic Exhaustion Attacks . . . . . . . . . . . . . 6
2.5. Unauthorized Neighbor or Routing Attacks . . . . . . . . . 6 2.5. Unauthorized Neighbor or Routing Attacks . . . . . . . . . 6
2.6. TCP RST Attacks . . . . . . . . . . . . . . . . . . . . . 7 2.6. TCP RST Attacks . . . . . . . . . . . . . . . . . . . . . 7
2.7. ICMP Attacks . . . . . . . . . . . . . . . . . . . . . . . 7 2.7. ICMP Attacks . . . . . . . . . . . . . . . . . . . . . . . 7
3. Typical Countermeasures . . . . . . . . . . . . . . . . . . . 7 3. Typical Countermeasures . . . . . . . . . . . . . . . . . . . 7
3.1. Address Filtering . . . . . . . . . . . . . . . . . . . . 7 3.1. Filtering Addresses in Packets . . . . . . . . . . . . . . 7
3.2. Route Filtering . . . . . . . . . . . . . . . . . . . . . 7 3.2. Filtering Addresses in Routing Updates . . . . . . . . . . 8
3.3. GTSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. GTSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. TCP-MD5 and Other Custom Authentication . . . . . . . . . 9 3.4. TCP-MD5 and Other Custom Authentication . . . . . . . . . 9
3.5. IPsec and IKE . . . . . . . . . . . . . . . . . . . . . . 9 3.5. IPsec and IKE . . . . . . . . . . . . . . . . . . . . . . 9
4. Protocol Analysis . . . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Analysis . . . . . . . . . . . . . . . . . . . . . . 9
4.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. BFD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Multicast Protocols (PIM, MSDP) . . . . . . . . . . . . . 11 4.5. Multicast Protocols (PIM, MSDP) . . . . . . . . . . . . . 11
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
A number of countermeasures for attacks against service provider A number of countermeasures for attacks against service provider
backbone network infrastructure have been specified or proposed, each backbone network infrastructure have been specified or proposed, each
of them usually targeting a subset of the problem space. There has of them usually targeting a subset of the problem space. There has
never been a more generic analysis of the actual problems, and which never been a more generic analysis of the actual problems, and which
countermeasures are even necessary (and where). This document tries countermeasures are even necessary (and where). This document tries
to provide that higher-level view. to provide that higher-level view.
skipping to change at page 4, line 16 skipping to change at page 4, line 16
This document assumes that the service provider is doing at least This document assumes that the service provider is doing at least
some form of address filtering at its border devices, i.e., by some form of address filtering at its border devices, i.e., by
ensuring that only the infrastructure nodes can use infrastructure ensuring that only the infrastructure nodes can use infrastructure
source IP addresses to talk to the other nodes in the infrastructure. source IP addresses to talk to the other nodes in the infrastructure.
So, for example, if a router sees an IP packet coming from a source So, for example, if a router sees an IP packet coming from a source
address assigned to another router in the backbone, it can be sure address assigned to another router in the backbone, it can be sure
the packet has been originated inside the backbone (assuming the the packet has been originated inside the backbone (assuming the
physical security or nodes in the backbone have not been subverted). physical security or nodes in the backbone have not been subverted).
NOTE: many SP networks do not fulfill this assumption, often due to
(1) legacy equipment which is not capable of line-rate filtering,
and/or (2) very large network with hundreds or even thousands of
devices is considered just too big to guard at the borders (and
sometimes can't be broken down to several smaller ones). Analysis of
this document does not and will not intend to cover these networks as
the problem space is substantially different and other approaches are
warranted. For example, [I-D.zinin-rtg-dos] suggested an alternative
and provides good analysis; cryptographic protection of all the
control traffic may be an option if "all bets are off".
This requirement can be satisfied by applying ingress filtering at This requirement can be satisfied by applying ingress filtering at
all the ISP borders [RFC2827][RFC3704], but just filtering all the ISP borders [RFC2827][RFC3704] for example, using feasible
infrastructure source IP addresses from the outside is also path strict uRPF towards customers and ingress access lists towards
peers and upstreams. However, just filtering the infrastructure IP
addresses used as source addresses from the outside is also
sufficient. Some may even implement this by blocking access to the sufficient. Some may even implement this by blocking access to the
infrastructure destination addresses at the border, but this document infrastructure destination addresses at the border, but this document
doesn't describe this approach as that has a number of other issues. doesn't describe this approach as that has a number of other issues.
Current operational practices are described in Current operational practices are described in
[I-D.ietf-opsec-current-practices]; while almost all ISPs are capable [I-D.ietf-opsec-current-practices]. Various filtering capabilities
of employing data plane filtering at the edges, at least one major have been discussed at more length in [I-D.ietf-opsec-filter-caps].
ISP is known not do be able to due to legacy hardware limitations.
Various filtering capabilities have been discussed at more length in
[I-D.ietf-opsec-filter-caps].
If this requirement cannot be satisfied, other approaches are
warranted. For example, [I-D.zinin-rtg-dos] suggested an alternative
(and in any case, provides good analysis); IPsec-protecting all the
control traffic may be an option if "all bets are off".
1.3. Threat Model 1.3. Threat Model
In the context of this document, threats are assumed to come from In the context of this document, threats are assumed to come from
external sources, either from customers or other networks. The external sources, either from customers or other networks. The
typical attacks are either meant to cause some form of denial of typical attacks are either meant to cause some form of denial of
service or to hijack or gain access to a service, such as: service or simply cause collateral damage, such as:
o DoS attacks directed at infrastructure (e.g., TCP RSTs, ICMP o DoS attacks directed at infrastructure (e.g., TCP RSTs, ICMP
attacks), attacks),
o DoS attacks directed at someone else but cause harm (e.g., too o Collateral damage from DoS and other attacks directed at someone
much traffic exceeds forwarding or control processor capacity), or else but causing harm to infrastructure or service (e.g., too much
traffic exceeds forwarding or control processor capacity), or
o Hijacking attacks (e.g., unauthorized routing advertisement, o Hijacking attacks (e.g., unauthorized routing advertisement,
access control attempt with a spoofed address). access control attempt with a spoofed address).
Other possible attack vectors include inside attacks (e.g., Other possible attack vectors but which are considered out of scope
compromised personnel or inadequately protected infrastructure include:
device) and lower-layer attacks as described in Section 2.1. While
the insider attack could be devastating, it can be mitigated by o ISP's systems being compromised through unauthorized access,
access controls and automatic configuration audits. As such the system vulnerability, etc.,
o Inside attacks (e.g., compromised personnel),
o Lower-layer attacks as described in Section 2.1.
While not perfect solutions, these can all be mitigated to some
degree by controls and automatic configuration audits. As such the
first order priority problems typically come from external sources. first order priority problems typically come from external sources.
2. Attack Vectors 2. Attack Vectors
This Section describes the most obvious attack vectors. This Section describes the most obvious attack vectors. Many of
these are also described in [I-D.iab-dos].
2.1. Lower-layer Attacks 2.1. Lower-layer Attacks
If an attacker has access to a (physical) link, it can obviously If an attacker has access to a (physical) link, it can obviously
cause downtime for the link. In many cases the downtime is not a cause downtime for the link. In many cases the downtime is not a
critical threat, as it can be quickly noticed, traffic rerouted, and critical threat, as it can be quickly noticed, traffic rerouted, and
the problem fixed. Some ISPs are more concerned about other forms of the problem fixed. Some ISPs are more concerned about other forms of
attacks: insertion of eavesdropping or man-in-the-middle devices. attacks: insertion of eavesdropping or man-in-the-middle devices.
Fortunately, installing such would require downtime, and insertion Fortunately, installing such would require downtime, and insertion
could be noticeable, e.g., as an unscheduled issue gets fixed on its could be noticeable, e.g., as an unscheduled issue gets fixed on its
skipping to change at page 5, line 37 skipping to change at page 5, line 51
lower-layer attack is deemed a concern, full protection for all the lower-layer attack is deemed a concern, full protection for all the
traffic should be provided and therefore this threat is not addressed traffic should be provided and therefore this threat is not addressed
in this document. in this document.
2.2. Generic DoS on the Router 2.2. Generic DoS on the Router
A typical attack is to overload a router using various techniques, A typical attack is to overload a router using various techniques,
e.g., by sending traffic exceeding the router's forwarding capacity, e.g., by sending traffic exceeding the router's forwarding capacity,
sending special transit packets that go through a "slow-path" sending special transit packets that go through a "slow-path"
processing (such functions may also come with problems of their own processing (such functions may also come with problems of their own
[BLOCKED]), or by sending some packets directed at the router itself. [BLOCKED]), or by sending some packets directed at the router itself
(e.g., to exceed the input queue for CPU processing).
Many of these techniques can be mitigated using implementation- Many of these techniques can be mitigated using implementation-
specific rate-limiting mechanisms, so they are not addressed further specific rate-limiting mechanisms, so they are not addressed further
in this memo. However, protocol designers should be advised to avoid in this memo. However, protocol designers should be advised to avoid
any designs that require noticing and processing any special packets any designs that require noticing and processing any special packets
from the transit traffic (e.g., messages marked with router alert from the transit traffic (e.g., messages marked with router alert
option). option).
2.3. Generic DoS on a Link 2.3. Generic DoS on a Link
Overloading the capacity of a link is often more difficult to prevent Overloading the capacity of a link is often more difficult to prevent
than a router DoS. Traffic is typically not automatically rerouted than a router DoS. Traffic is typically not automatically rerouted
and even if it did, doing so could make the issue worse unless there and even if it was, doing so could make the issue worse unless there
is ample spare capacity. is ample spare capacity.
Mitigation methods include monitoring the usage status of links, Mitigation methods include monitoring the usage status of links,
prioritizing or deprioritizing certain kinds of traffic using DSCPs, prioritizing or deprioritizing certain kinds of traffic using DSCPs,
or devising some form of rate-limiters. or devising some form of rate-limiters.
2.4. Cryptographic Exhaustion Attacks 2.4. Cryptographic Exhaustion Attacks
A special form of DoS are attacks which target a protocol that uses A special form of DoS are attacks which target a protocol that uses
cryptographic mechanisms, for example TCP-MD5 or IPsec. The attacker cryptographic mechanisms, for example TCP-MD5 or IPsec. The attacker
sends valid protocol messages with cryptographic signatures or other sends valid protocol messages with cryptographic signatures or other
properties to the router, which is forced to perform cryptographic properties to the router, which is forced to perform cryptographic
validation of the message. If the cryptographic operations are validation of the message. If the cryptographic operations are
computationally expensive, the attack might succeed easier than with computationally expensive, the attack might succeed easier than with
other generic DoS mechanisms. Cryptographic protocols employing other generic DoS mechanisms. Cryptographic protocols employing
primitives such as stateless cookies, puzzles or return routability primitives such as stateless cookies, puzzles or return routability
are typically more resistant to this kind of attacks. are typically more resistant to this kind of attacks.
Some implementation-specific mitigation techniques (rate-limiting Some implementation-specific mitigation techniques (rate-limiting
etc.) have been deployed, but as this affects the choice of a etc.) have been deployed. Protocol design should take these attacks
countermeasure due to protocol design. into account.
2.5. Unauthorized Neighbor or Routing Attacks 2.5. Unauthorized Neighbor or Routing Attacks
Unauthorized nodes can obtain a routing protocol adjacency on links Unauthorized nodes can obtain a routing protocol adjacency on links
where an IGP has been enabled by misconfiguration, or where where an IGP has been enabled by misconfiguration, or where
authentication is not used. This may result in many different kinds authentication is not used. This may result in many different kinds
of attacks, for example traffic redirection of attacks, for example traffic redirection
[I-D.ietf-rpsec-routing-threats]. [I-D.ietf-rpsec-routing-threats].
At least in theory, while it may not be possible to establish an At least in theory, while it may not be possible to establish an
adjacency from outside the link, it may be possible to inject packets adjacency from outside the link, it may be possible to inject packets
as if the adjacency had been established (e.g., OSPF in Section 3.1.2 as if the adjacency had been established (e.g., OSPF in Section 4.1.2
of [I-D.ietf-rpsec-ospf-vuln]). of [I-D.ietf-rpsec-ospf-vuln]).
Protocols such as BGP and MSDP that process routing information from Protocols such as BGP and MSDP that process routing information from
untrusted, external sources may also be attacked, for example by an untrusted, external sources may also be attacked, for example by an
unauthorized advertisement of a prefix. unauthorized advertisement of a prefix.
Special care needs to be made to ensure that unauthorized neighbors Special care needs to be made to ensure that unauthorized neighbors
are prevented (e.g., by regular configuration audits and OSPF are prevented (e.g., by regular configuration audits and OSPF
protocol filtering at borders). On the other hand, routing attack protocol filtering at borders). On the other hand, routing attack
threats from valid neighbors can be minimized via appropriate route threats from valid neighbors can be slightly mitigated via
filtering. appropriate route filtering.
2.6. TCP RST Attacks 2.6. TCP RST Attacks
TCP sessions can be closed by attackers that can send a TCP RST TCP sessions can be closed by attackers that can send a TCP RST
packet with guessed spoofed endpoint identifiers and a sufficiently packet with guessed spoofed endpoint identifiers and a sufficiently
close sequence number. The attacks and defenses have been described close sequence number. The attacks and defenses have been described
at length in [I-D.ietf-tcpm-tcp-antispoof]. One particular approach at length in [I-D.ietf-tcpm-tcp-antispoof]. One particular approach
is modifying the TCP state machine [I-D.ietf-tcpm-tcpsecure]. is modifying the TCP state machine [I-D.ietf-tcpm-tcpsecure].
2.7. ICMP Attacks 2.7. ICMP Attacks
A slightly newer attack is employing ICMP by sending an ICMP type A slightly newer attack is employing ICMP by sending an ICMP type
that indicates a hard error condition. ICMP errors must be that indicates a hard error condition. ICMP errors must be
propagated to applications, and most applications heed the errors as propagated to the upper layer, and most applications heed the errors
they should by closing a connection or session. ICMP attacks and as they should by closing a connection or session. ICMP attacks and
defenses against TCP have been extensively described in defenses against TCP have been extensively described in
[I-D.ietf-tcpm-icmp-attacks]. [I-D.ietf-tcpm-icmp-attacks]. Most TCP stacks have since then been
fixed [CVE].
It is also possible to execute ICMP attacks against other protocols It is also possible to execute ICMP attacks against other protocols
such as UDP or IPsec, but the impact and whether/how these protocols such as UDP or IPsec, but the impact and whether/how these protocols
demultiplex received errors have not been extensively studied. IPsec demultiplex received errors have not been extensively studied. IPsec
is protected by ICMP attacks through a lot of assumptions (e.g., that is protected by ICMP attacks through a number of assumptions (e.g.,
only ICMP errors from the end-point are accepted) or manual that only ICMP errors from the end-point are accepted) or manual
configuration. configuration.
3. Typical Countermeasures 3. Typical Countermeasures
This Section describes some of the most common countermeasures This Section describes some of the most common countermeasures
applied today. This just introduces the techniques; the afforded applied today. This just introduces the techniques; the afforded
protection is analyzed in Section 4 in the context of each protocol. protection is analyzed in Section 4 in the context of each protocol.
3.1. Address Filtering 3.1. Filtering Addresses in Packets
As described in the first section, this document assumes that the As described in the first section, this document assumes that the
internal infrastructure is secure from spoofed messages that purport internal infrastructure is secure from spoofed messages that purport
to come from inside the infrastructure. More fine-grained, router- to come from inside the infrastructure. More fine-grained, router-
specific filters are sometimes deployed as well. specific filters are sometimes deployed as well.
It is possible to hide the infrastructure by using private or non- It is possible to hide the infrastructure by using private or non-
advertised addressing, but this has numerous drawbacks such as advertised addressing, but this has numerous drawbacks such as
breaking address filtering and traceroute, not protecting from the breaking address filtering and traceroute, not protecting from the
ISP's customers that use a default route, etc. so this document ISP's customers that use a default route, etc. so this document
doesn't recommand doing so. doesn't recommand doing so.
3.2. Route Filtering In addition, it may also make sense to ensure that egress packets
have the ISP's own source addresses and/or that ingress packets
arrive with either multicast/broadcast or ISP's own destination
addresses. These ensure that in case your own filtering fails, no
bad traffic leaks out and prevent certain classes of abuse from peers
(e.g., stealing transit by static routing).
3.2. Filtering Addresses in Routing Updates
Similar principles as used in address filtering can be used to Similar principles as used in address filtering can be used to
mitigate routing attacks. Specifically, reject any equal or more mitigate routing attacks. Specifically, reject any equal or more
specific incoming routing advertisements to the ISP's address space specific incoming routing advertisements to the ISP's address space
unless explicitly authorized. Further, monitor the filtered prefixes unless explicitly authorized. Further, monitor the filtered prefixes
and use public services (such as RIPE's MyASN [MYASN]) to monitor the and use public services (such as RIPE's MyASN [MYASN]) to monitor the
correctness of advertisements globally. correctness of advertisements globally.
As with address filtering, such routing advertisements might still be
processed by other networks, but at least these steps prevent
hijacking inside the ISP's own network and allow monitoring of most
unauthorized attempts.
It may also make sense to filter out in a similar fashion the
advertisements or more specifics of IX peering blocks where the ISP
connects to. These could be advertised by an attacker to mess up
forwarding next-hops.
In addition, especially in regions where the operational practice is In addition, especially in regions where the operational practice is
to keep Internet Routing Registry (IRR) in sync, it may be possible to keep Internet Routing Registry (IRR) in sync, it may be possible
to restrict the prefixes accepted from a peer or a customer to an to restrict the prefixes accepted from a peer or a customer to an
automatically generated list. In any case, many operators define a automatically generated list. In any case, many operators define a
maximum prefix limit per peer (which typically resets the session if maximum prefix limit per peer (which typically resets the session if
exceeded) to prevent misconfiguration or overload attacks. exceeded) to prevent misconfiguration (e.g., unintentional
deaggregation) or overload attacks.
As with address filtering, such routing advertisements might still be
processed by other networks, but at least these steps prevent
hijacking inside the ISP's own network and allow monitoring of most
unauthorized attempts.
3.3. GTSM 3.3. GTSM
GTSM [I-D.ietf-rtgwg-rfc3682bis] is a technique where the sender of a GTSM [I-D.ietf-rtgwg-rfc3682bis] is a technique where the sender of a
packet sets the TTL/Hop Count to 255 and the receiver verifies it's packet sets the TTL/Hop Count to 255 and the receiver verifies it's
still 255 (or some other preconfigured value). GTSM can be used to still 255 (or some other preconfigured value). GTSM can be used to
protect from off-link attacks (especially spoofing). This applies protect from off-link attacks (especially spoofing). This applies
when GTSM-enabled control traffic is inside a single link: any when GTSM-enabled control traffic is inside a single link: any
packets coming from outside the link can summarily be discarded as packets coming from outside the link can summarily be discarded as
they have a TTL/Hop Count smaller than 255. they have a TTL/Hop Count smaller than 255.
The open issue at the moment is how GTSM handles TCP RSTs. I.e., 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 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 with TTL=255 and verified to come with TTL=255 (or a configured
value)? Do implementations already do this? Is there a sensible value)? Some implementations already send out all packets with
transition plan or need to make a change if any? Note that this has TTL=255, but receipt verification is not performed. Is there a
only limited impact on GTSM's security as other TCP RST mitigation sensible transition plan or need to make a change if any? Note that
techniques still apply. this has only limited impact on GTSM's security as other TCP RST
mitigation techniques still apply.
NOTE IN DRAFT: the following paragraph should be removed in a future NOTE IN DRAFT: the following paragraph should be removed in a future
revision, to be placed to the GTSMbis draft. revision, to be placed to the GTSMbis draft.
We suggest that the GTSM spec is amended so that TCP RSTs relating to We suggest that the GTSM spec is amended so that TCP RSTs relating to
a GTSM-enabled protocol port MUST be sent with TTL=255. (Note that a GTSM-enabled protocol port MUST be sent with TTL=255. The
this will require a kernel modification, and a means to specify to recipient's behaviour SHOULD be configurable, and it is RECOMMENDED
the kernel which ports relate to GTSM.). The recipient's behaviour that the default be to discard messages where TTL is not 255 (or 255-
SHOULD be configurable, and it is RECOMMENDED that the default be to TrustRadius).
discard messages where TTL is not 255 (or 255-TrustRadius).
3.4. TCP-MD5 and Other Custom Authentication 3.4. TCP-MD5 and Other Custom Authentication
At least BGP, MSDP, and LDP are able to use the TCP-MD5 signature At least BGP, MSDP, and LDP are able to use the TCP-MD5 signature
option to verify the authenticity of control packets. TCP-MD5 uses option to verify the authenticity of control packets. TCP-MD5 uses
manually configured static keys, so changing them typically resets manually configured static keys, and changing them must be a
the protocol session, so the solution is sub-optimal in cases where coordinated event to prevent session reset. Due to the operational
the security procedures require (e.g., after an employee leaves the cost of re-keying, the solution is sub-optimal in cases where (rather
organization) that the keys must be easily and often changeable. paranoid) security procedures require (e.g., after an employee leaves
the organization) that the keys must be easily and often changeable.
Using TCP-MD5 and other similar authentication mechanisms (e.g., for Using TCP-MD5 and other similar authentication mechanisms (e.g., for
IGPs or BFD) also opens an attack vector for cryptographic exhaustion IGPs or BFD) also opens an attack vector for cryptographic exhaustion
attacks unless implementations have appropriate mechanisms to attacks unless implementations have appropriate mechanisms to
throttle or otherwise manage heavy cryptographic operations. throttle or otherwise manage heavy cryptographic operations.
3.5. IPsec and IKE 3.5. IPsec and IKE
IPsec and IKE have been proposed as a more comprehensive IPsec and IKE have been proposed as a more comprehensive
countermeasure, but these protocols also require a lot of heavyweight countermeasure, but these protocols also require a lot of heavyweight
skipping to change at page 9, line 34 skipping to change at page 10, line 7
processing. Vendors have also expressed difficulty in applying IPsec processing. Vendors have also expressed difficulty in applying IPsec
to control traffic protection. to control traffic protection.
4. Protocol Analysis 4. Protocol Analysis
This Section briefly discusses the protocol-specific attack This Section briefly discusses the protocol-specific attack
properties below. properties below.
ICMP attacks apply to all the IP protocols at least to some degree. ICMP attacks apply to all the IP protocols at least to some degree.
There is no reasonable way to appropriately protect from these There is no reasonable way to appropriately protect from these
attacks by operative methods: the vendors should implement attacks by operative methods such as filtering: the vendors should
countermeasures described in [I-D.ietf-tcpm-icmp-attacks] to mitigate implement countermeasures described in [I-D.ietf-tcpm-icmp-attacks]
these attacks. to mitigate these attacks.
4.1. OSPF 4.1. OSPF
OSPF attacks have already been analyzed [I-D.ietf-rpsec-ospf-vuln]. OSPF attacks have already been analyzed [I-D.ietf-rpsec-ospf-vuln].
In this context the most important of them are: (1) preventing In this context the most important of them are preventing (1)
misconfiguration and unauthorized neighbors, and (2) ensuring off- misconfiguration and unauthorized neighbors, and (2) off-path
path directed attacks as described in Section 3.1.2 of directed attacks as described in Section 4.1.2 of
[I-D.ietf-rpsec-ospf-vuln]. [I-D.ietf-rpsec-ospf-vuln].
The former requires configuration change procedures and regular The former requires configuration change procedures and regular
audits of OSPF configuration, and disabling OSPF adjacencies on audits of OSPF configuration, and disabling OSPF adjacencies on
customer-facing links, or adding authentication when there are customer-facing links, or adding authentication when there are
multiple routers. The latter requires using OSPF authentication, multiple routers. The latter requires using OSPF authentication,
dropping all OSPF traffic at all the borders, or moving to another, dropping all OSPF traffic at all the borders, or moving to another,
less vulnerable protocol (e.g., IS-IS). less vulnerable protocol (e.g., IS-IS).
OSPF is also used to some degree with provider-provisioned VPNs by OSPF is also used to some degree with provider-provisioned VPNs by
the customers. In such scenarios, strict route filtering needs to be the customers. In such scenarios, strict route filtering needs to be
applied to ensure only the valid prefixes are accepted. applied to ensure only the valid prefixes are accepted.
4.2. IS-IS 4.2. IS-IS
Routing IP with IS-IS has gained popularity in the backbone networks Routing IP with IS-IS has gained popularity in the backbone networks
lately. As IS-IS does not use IP, it is sufficient to prevent lately. As IS-IS does not use IP as its control protocol, external
misconfiguration and unauthorized neighbors. Thus most of the attackers cannot attack IS-IS in the same way as they can attack
attacks and countermeasures of OSPF apply to IS-IS as well: OSPF. Hence it is sufficient to prevent misconfiguration and
unauthorized neighbors, using similar countermeasures as with OSPF:
configuration change procedures and regular configuration audits and configuration change procedures and regular configuration audits and
disabling IS-IS adjacencies on customer-facing links, or adding disabling IS-IS adjacencies on customer-facing links, or adding
authentication when there are multiple routers. authentication when there are multiple routers.
4.3. BFD 4.3. BFD
Bidirectional Forwarding Detection (BFD) detects faults in the Bidirectional Forwarding Detection (BFD) detects faults in the
forwarding path between two endpoints. As a generic mechanism, it forwarding path between two endpoints. As a generic mechanism, it
can be applied to a number of protocols (e.g., OSPF, IS-IS, BGP, can be applied to a number of protocols (e.g., OSPF, IS-IS, BGP,
MPLS, or static routes). MPLS, or static routes).
skipping to change at page 10, line 48 skipping to change at page 11, line 23
common and easier to protect and applying GTSM provides first-order common and easier to protect and applying GTSM provides first-order
resistance to off-link attackers. resistance to off-link attackers.
In any case, assuming address filtering, the session can only be In any case, assuming address filtering, the session can only be
reset by the peer, or by attacks from the direction of the peer's reset by the peer, or by attacks from the direction of the peer's
network (e.g., through lack of peer's border filtering). One can network (e.g., through lack of peer's border filtering). One can
therefore question the necessity of further protection as the peer therefore question the necessity of further protection as the peer
can only shoot itself in the foot by killing the BGP session or can only shoot itself in the foot by killing the BGP session or
allowing the BGP session be killed through negligence. allowing the BGP session be killed through negligence.
There is one exception to the above: if the customer is multihomed
through multiple ISPs and the addresses used for the peering session
are from the customer's address block. In such scenarios, using each
ISP's respective addresses for the peering link might be the simplest
approach.
If the link is not trusted (e.g., in some large Ethernet-based If the link is not trusted (e.g., in some large Ethernet-based
Internet Exchange points), it may also be desirable to ensure that Internet Exchange points), it may also be desirable to ensure that
peers are not able to reset others' sessions, so a mechanism like peers are not able to reset others' sessions, so a mechanism like
TCP-MD5 may be appropriate. One should note that the security TCP-MD5 may be appropriate. One should note that the security
requirements are not necessarily very high as the attacker should requirements are not necessarily very high as the attacker should
already be easily traceable on a single link, and thus re-keying may already be easily traceable on a single link, and thus re-keying may
not be worth the trouble. not be worth the trouble.
As BGP processes data heard from external sources, the routing data As BGP processes data heard from external sources, the routing data
can be modified in numerous ways, e.g., to create arbitrarily complex can be modified in numerous ways, e.g., to create arbitrarily complex
skipping to change at page 12, line 22 skipping to change at page 13, line 5
Exchange points) could be warranted. Exchange points) could be warranted.
6. IANA Considerations 6. IANA Considerations
This memo makes no request to IANA. This memo makes no request to IANA.
7. Acknowledgements 7. Acknowledgements
George Jones suggested improvements to the initial version of this George Jones suggested improvements to the initial version of this
draft. Further feedback was received from Sean P. Turner, Seo Boon draft. Further feedback was received from Sean P. Turner, Seo Boon
NG, Warren Kumari, Hank Nussbacher, and Jonathan Trostle. NG, Warren Kumari, Hank Nussbacher, Jonathan Trostle, Iljitsch van
Beijnum, and Barry Greene.
8. Security Considerations 8. Security Considerations
This document does not define a protocol but rather describes and This document does not define a protocol but rather describes and
analyzes the security properties and countermeasures in existing analyzes the security properties and countermeasures in existing
service provider backbone network infrastructures. service provider backbone network infrastructures.
The most important issues that should be noted are its security The most important issues that should be noted are its security
assumptions: assumptions:
o We require at least certain degree of address filtering at
borders, or else all bets are off. This assumption is notably NOT
satisfied by a number of networks.
o The main concern is an external attack (from customers or some o The main concern is an external attack (from customers or some
other network); lower-layer attacks are not considered a other network); lower-layer attacks are not considered a
particular concern for routing protocols. particular concern for routing protocols.
o We require at least certain degree of address filtering at
borders, or else all bets are off.
o Generic DoS attacks against routers can be mitigated using o Generic DoS attacks against routers can be mitigated using
implementation-specific measures. implementation-specific measures.
There are a number of activities network operators have to do in There are a number of actions for network operators in order to
order to protect the network (e.g., filtering OSPF packets at the protect the network (e.g., filtering OSPF packets at the edges or
edges or auditing IGP configurations). There are also lessons to be auditing IGP configurations). There are also lessons to be learned
learned for protocol designers (e.g., OSPF external attacks, ICMP for protocol designers (e.g., OSPF external attacks, ICMP attacks
attacks against non-TCP, use of GTSM). Many of the issues listed against non-TCP, use of GTSM). Many of the issues listed also depend
also depend on vendors to implement effective, vendor-specific rate- on vendors to implement effective, vendor-specific rate-limiting
limiting techniques. techniques.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-mboned-mroutesec] [I-D.ietf-mboned-mroutesec]
Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast
Routing Security Issues and Enhancements", Routing Security Issues and Enhancements",
draft-ietf-mboned-mroutesec-04 (work in progress), draft-ietf-mboned-mroutesec-04 (work in progress),
October 2004. October 2004.
[I-D.ietf-opsec-current-practices] [I-D.ietf-opsec-current-practices]
Kaeo, M., "Operational Security Current Practices", Kaeo, M., "Operational Security Current Practices",
draft-ietf-opsec-current-practices-03 (work in progress), draft-ietf-opsec-current-practices-05 (work in progress),
May 2006. July 2006.
[I-D.ietf-rpsec-ospf-vuln] [I-D.ietf-rpsec-ospf-vuln]
Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Jones, E. and O. Moigne, "OSPF Security Vulnerabilities
Analysis", draft-ietf-rpsec-ospf-vuln-01 (work in Analysis", draft-ietf-rpsec-ospf-vuln-02 (work in
progress), December 2004. progress), June 2006.
[I-D.ietf-rpsec-routing-threats] [I-D.ietf-rpsec-routing-threats]
Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", draft-ietf-rpsec-routing-threats-07 Routing Protocols", draft-ietf-rpsec-routing-threats-07
(work in progress), October 2004. (work in progress), October 2004.
[I-D.ietf-rtgwg-rfc3682bis] [I-D.ietf-rtgwg-rfc3682bis]
Gill, V., "The Generalized TTL Security Mechanism (GTSM)", Gill, V., "The Generalized TTL Security Mechanism (GTSM)",
draft-ietf-rtgwg-rfc3682bis-05 (work in progress), draft-ietf-rtgwg-rfc3682bis-05 (work in progress),
April 2005. April 2005.
skipping to change at page 14, line 16 skipping to change at page 14, line 47
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, January 2006. RFC 4272, January 2006.
9.2. Informative References 9.2. Informative References
[BLOCKED] Cisco Systems, "Cisco Security Advisory: Cisco IOS [BLOCKED] Cisco Systems, "Cisco Security Advisory: Cisco IOS
Interface Blocked by IPv4 Packets", 2004, <http:// Interface Blocked by IPv4 Packets", 2004, <http://
www.cisco.com/warp/public/707/ www.cisco.com/warp/public/707/
cisco-sa-20030717-blocked.shtml>. cisco-sa-20030717-blocked.shtml>.
[CVE] CVE-2004-0790, "Multiple TCP/IP and ICMP implementations
allow remote attackers to cause a denial of service (reset
TCP connections) via spoofed ICMP error messages, aka the
"blind connection-reset attack."", 2004, <http://
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0790>.
[I-D.iab-dos]
Rescorla, E. and M. Handley, "Internet Denial of Service
Considerations", draft-iab-dos-04 (work in progress),
June 2006.
[I-D.ietf-mboned-routingarch] [I-D.ietf-mboned-routingarch]
Savola, P., "Overview of the Internet Multicast Routing Savola, P., "Overview of the Internet Multicast Routing
Architecture", draft-ietf-mboned-routingarch-03 (work in Architecture", draft-ietf-mboned-routingarch-04 (work in
progress), March 2006. progress), June 2006.
[I-D.ietf-opsec-filter-caps] [I-D.ietf-opsec-filter-caps]
Morrow, C., "Filtering Capabilities for IP Network Morrow, C., "Filtering Capabilities for IP Network
Infrastructure", draft-ietf-opsec-filter-caps-01 (work in Infrastructure", draft-ietf-opsec-filter-caps-01 (work in
progress), May 2006. progress), May 2006.
[I-D.ietf-tcpm-tcpsecure] [I-D.ietf-tcpm-tcpsecure]
Stewart, R. and M. Dalal, "Improving TCP's Robustness to Stewart, R. and M. Dalal, "Improving TCP's Robustness to
Blind In-Window Attacks", draft-ietf-tcpm-tcpsecure-04 Blind In-Window Attacks", draft-ietf-tcpm-tcpsecure-05
(work in progress), February 2006. (work in progress), June 2006.
[I-D.savola-pim-lasthop-threats] [I-D.savola-pim-lasthop-threats]
Savola, P., "Last-hop Threats to Protocol Independent Lingard, J. and P. Savola, "Last-hop Threats to Protocol
Multicast (PIM)", draft-savola-pim-lasthop-threats-01 Independent Multicast (PIM)",
(work in progress), January 2005. draft-savola-pim-lasthop-threats-02 (work in progress),
June 2006.
[I-D.zinin-rtg-dos] [I-D.zinin-rtg-dos]
Zinin, A., "Protecting Internet Routing Infrastructure Zinin, A., "Protecting Internet Routing Infrastructure
from Outsider DoS Attacks", draft-zinin-rtg-dos-02 (work from Outsider DoS Attacks", draft-zinin-rtg-dos-02 (work
in progress), May 2005. in progress), May 2005.
[MYASN] RIPE NCC, "MyASn System", [MYASN] RIPE NCC, "MyASn System",
<http://www.ris.ripe.net/myasn.html>. <http://www.ris.ripe.net/myasn.html>.
Author's Address Author's Address
 End of changes. 46 change blocks. 
97 lines changed or deleted 148 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/