draft-ietf-babel-source-specific-05.txt   draft-ietf-babel-source-specific-06.txt 
Network Working Group M. Boutier Network Working Group M. Boutier
Internet-Draft J. Chroboczek Internet-Draft J. Chroboczek
Intended status: Standards Track IRIF, University of Paris-Diderot Intended status: Standards Track IRIF, University of Paris-Diderot
Expires: October 13, 2019 April 11, 2019 Expires: April 13, 2021 October 10, 2020
Source-Specific Routing in Babel Source-Specific Routing in Babel
draft-ietf-babel-source-specific-05 draft-ietf-babel-source-specific-06
Abstract Abstract
Source-specific routing (also known as Source-Address Dependent Source-specific routing (also known as Source-Address Dependent
Routing, SADR) is an extension to traditional next-hop routing where Routing, SADR) is an extension to traditional next-hop routing where
packets are forwarded according to both their destination and their packets are forwarded according to both their destination and their
source address. This document describes an extension for source- source address. This document describes an extension for source-
specific routing to the Babel routing protocol. specific routing to the Babel routing protocol.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on October 13, 2019. This Internet-Draft will expire on April 13, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and background . . . . . . . . . . . . . . . . . 2 1. Introduction and background . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 4 3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 3
3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4 3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4
3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4 3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4
4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4 4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5
5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6
5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 6 5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 6
6. Compatibility with the base protocol . . . . . . . . . . . . 7 6. Compatibility with the base protocol . . . . . . . . . . . . 7
6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7 6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7
6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 8 6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 8
7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8 7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8 7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8
7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9 7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9
7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9 7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9
7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9 7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Security considerations . . . . . . . . . . . . . . . . . . . 10 9. Security considerations . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction and background 1. Introduction and background
The Babel routing protocol [BABEL] is a distance vector routing The Babel routing protocol [BABEL] is a distance vector routing
protocol for next-hop routing. In next-hop routing, each node protocol for next-hop routing. In next-hop routing, each node
maintains a forwarding table which maps destination prefixes to next maintains a forwarding table which maps destination prefixes to next
hops. The forwarding decision is a per-packet operation which hops. The forwarding decision is a per-packet operation which
depends on the destination address of the packets and on the entries depends on the destination address of the packets and on the entries
of the forwarding table. When a packet is about to be routed, its of the forwarding table. When a packet is about to be routed, its
destination address is compared to the prefixes of the routing table: destination address is compared to the prefixes of the routing table:
the entry with the most specific prefix containing the destination the entry with the most specific prefix containing the destination
address of the packet is chosen, and the packet is forwarded to the address of the packet is chosen, and the packet is forwarded to the
associated next-hop. Next-hop routing is a simple, well understood associated next-hop. Next-hop routing is a simple, well understood
paradigm that works satisfactorily in a large number of cases. paradigm that works satisfactorily in a large number of cases.
Source-specific routing [SS-ROUTING], or Source Address Dependent Source-specific routing [SS-ROUTING], or Source Address Dependent
Routing (SADR) [DSR], is a modest extension to next-hop routing where Routing (SADR), is a modest extension to next-hop routing where the
the forwarding decision depends not only on the destination address forwarding decision depends not only on the destination address but
but also on the source address of the packet being routed, which also on the source address of the packet being routed, which makes it
makes it possible for two packets with the same destination but possible for two packets with the same destination but different
different source addresses to be routed following different paths. source addresses to be routed following different paths. The
forwarding tables are extended to map pairs of prefixes (destination,
The forwarding tables are extended to map pairs of prefixes source) to next hops. When multiple entries match a given packet,
(destination, source) to next hops. When multiple entries match a the one with the most specific destination prefix is chosen, and, in
given packet, the one with the most specific destination prefix is the case of equally specific destination prefixes, the one with the
chosen, and, in the case of equally specific destination prefixes, most specific source prefix.
the one with the most specific source prefix.
The main application of source-specific routing is a form of The main application of source-specific routing is a form of
multihoming known as multihoming with multiple addresses. When using multihoming known as multihoming with multiple addresses. When using
this technique in a network connected to multiple providers, every this technique in a network connected to multiple providers, every
host is assigned multiple addresses, one per provider. When a host host is assigned multiple addresses, one per provider. When a host
sources a packet, it picks one of its addresses as the source sources a packet, it picks one of its addresses as the source
address, and source-specific routing is used to route the packet to address, and source-specific routing is used to route the packet to
an edge router that is connected to the corresponding provider, which an edge router that is connected to the corresponding provider, which
is compatible with [BCP84]. Unlike classical multihoming, this is compatible with [BCP84]. Unlike classical multihoming, this
technique is applicable to small networks, as it does not require the technique is applicable to small networks, as it does not require the
use of provider-independent addresses, or cause excessive growth of use of provider-independent addresses, or cause excessive growth of
the global routing table. More details are given in [SS-ROUTING] and the global routing table. More details are given in [SS-ROUTING].
[DSR].
This document describes a source-specific routing extension for the This document describes a source-specific routing extension for the
Babel routing protocol [BABEL]. This involves minor changes to the Babel routing protocol [BABEL]. This involves minor changes to the
data structures, which must include a source prefix in addition to data structures, which must include a source prefix in addition to
the destination prefix already present, and some changes to the the destination prefix already present, and some changes to the
Update, Route Request and Seqno Request TLVs, which are extended with Update, Route Request and Seqno Request TLVs, which are extended with
a source prefix. The source prefix is encoded using a mandatory sub- a source prefix. The source prefix is encoded using a mandatory sub-
TLV ([BABEL] Section 4.4). TLV ([BABEL] Section 4.4).
2. Specification of Requirements 2. Specification of Requirements
skipping to change at page 5, line 12 skipping to change at page 5, line 5
given packet without one necessarily being more specific than the given packet without one necessarily being more specific than the
other. Consider for example the following routing table: other. Consider for example the following routing table:
destination source next-hop destination source next-hop
2001:DB8:0:1::/64 ::/0 A 2001:DB8:0:1::/64 ::/0 A
::/0 2001:DB8:0:2::/64 B ::/0 2001:DB8:0:2::/64 B
This specifies that all packets with destination in 2001:DB8:0:1::/64 This specifies that all packets with destination in 2001:DB8:0:1::/64
are to be routed through A, while all packets with source in are to be routed through A, while all packets with source in
2001:DB8:0:2::/64 are to be routed through B. A packet with source 2001:DB8:0:2::/64 are to be routed through B. A packet with source
2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both rules, 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57 matches both
although neither is more specific than the other. A choice is entries, although neither is more specific than the other. A choice
necessary, and unless the choice being made is the same on all is necessary, and unless the choice being made is the same on all
routers in a routing domain, persistent routing loops may occur. routers in a routing domain, persistent routing loops may occur.
More details are given in Section IV.C of [SS-ROUTING]. More details are given in Section IV.C of [SS-ROUTING].
A Babel implementation MUST choose routing table entries by using the A Babel implementation MUST choose routing table entries by using the
so-called destination-first ordering, where a routing table entry R1 so-called destination-first ordering, where a routing table entry R1
is preferred to a routing table entry R2 when either R1's destination is preferred to a routing table entry R2 when either R1's destination
prefix is more specific than R2's, or the destination prefixes are prefix is more specific than R2's, or the destination prefixes are
equal and R1's source prefix is more specific than R2's. (In more equal and R1's source prefix is more specific than R2's. (In other
formal terms, routing table entries are compared using the words, routing table entries are compared using the lexicographic
lexicographic product of the destination prefix ordering by the product of the destination prefix ordering by the source prefix
source prefix ordering.) This is consistent with the behaviour ordering.)
described in Section 3.3 of [DSR].
In practice, this means that a source-specific Babel implementation In practice, this means that a source-specific Babel implementation
must take care that any lower layer that performs packet forwarding must take care that any lower layer that performs packet forwarding
obey this semantics. More precisely: obey this semantics. More precisely:
o If the lower layers implement the destination-first ordering, then o If the lower layers implement the destination-first ordering, then
the Babel implementation MAY use them directly; the Babel implementation SHOULD use them directly;
o If the lower layers can hold source-specific routes, but not with o If the lower layers can hold source-specific routes, but not with
the right semantics, then the Babel implementation MUST the right semantics, then the Babel implementation MUST either
disambiguate the routing table by using a suitable disambiguation silently ignore any source-specific routes, or disambiguate the
algorithm (see Section V.B of [SS-ROUTING] for such an algorithm); routing table by using a suitable disambiguation algorithm (see
Section V.B of [SS-ROUTING] for such an algorithm);
o If the lower layers cannot hold source-specific routes, then a o If the lower layers cannot hold source-specific routes, then a
Babel implementation MUST silently ignore (drop) any source- Babel implementation MUST silently ignore any source-specific
specific routes. routes.
5. Protocol Operation 5. Protocol Operation
This extension does not fundamentally change the operation of the This extension does not fundamentally change the operation of the
Babel protocol, and we therefore only describe differences between Babel protocol, and we therefore only describe differences between
the original protocol and the extended protocol. the original protocol and the extended protocol.
In the original protocol, three TLVs carry a destination prefix: In the original protocol, three TLVs carry a destination prefix:
Updates, Route Requests and Seqno Requests. This specification Updates, Route Requests and Seqno Requests. This specification
extends these messages to optionally carry a Source Prefix sub-TLV, extends these messages to optionally carry a Source Prefix sub-TLV,
skipping to change at page 8, line 51 skipping to change at page 8, line 45
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 128 | Length | Source Plen | Source Prefix... | Type = 128 | Length | Source Plen | Source Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields: Fields:
Type Set to 128 to indicate a Source Prefix sub-TLV. Type Set to 128 to indicate a Source Prefix sub-TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, in octets, exclusive of the Type
fields. and Length fields.
Source Plen The length of the advertised source prefix. This MUST Source Plen The length of the advertised source prefix. This MUST
NOT be 0. NOT be 0.
Source Prefix The source prefix being advertised. This field's size Source Prefix The source prefix being advertised. This field's size
is (Source Plen)/8 rounded upwards. is (Source Plen)/8 octets rounded upwards.
The contents of the Source Prefix sub-TLV are interpreted according The contents of the Source Prefix sub-TLV are interpreted according
to the AE of the enclosing TLV. If a TLV with AE equal to 0 contains to the AE of the enclosing TLV. If a TLV with AE equal to 0 contains
a Source Prefix sub-TLV, then the whole TLV MUST be ignored. a Source Prefix sub-TLV, then the whole TLV MUST be ignored.
Similarly, if a TLV contains multiple Source Prefix sub-TLVs, then Similarly, if a TLV contains multiple Source Prefix sub-TLVs, then
the whole TLV MUST be ignored. the whole TLV MUST be ignored.
Note that this sub-TLV is a mandatory sub-TLV. Therefore, as Note that this sub-TLV is a mandatory sub-TLV. Therefore, as
described in Section 4.4 of [BABEL], the whole TLV MUST be ignored if described in Section 4.4 of [BABEL], the whole TLV MUST be ignored if
that sub-TLV is not understood (or malformed). Otherwise, routing that sub-TLV is not understood (or malformed). Otherwise, routing
skipping to change at page 10, line 15 skipping to change at page 10, line 13
pair of a destination and source prefix. pair of a destination and source prefix.
8. IANA Considerations 8. IANA Considerations
IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV
in the Babel sub-TLV types registry. in the Babel sub-TLV types registry.
9. Security considerations 9. Security considerations
The extension defined in this document adds a new sub-TLV to three The extension defined in this document adds a new sub-TLV to three
TLVs already present in the original Babel protocol, and does not in TLVs already present in the original Babel protocol, and does not
itself change the security properties of the protocol. However, change the security properties of the protocol itself. However, the
source-specific routing gives more control over routing to the additional flexibility provided by source-specific routing might
sending hosts, which might have security implications (see Section 8 invalidate the assumptions made by some network administrators, which
of [DSR]). could conceivably lead to security issues.
For example, a network administrator might be tempted to abuse route
filtering (Appendix C of [BABEL]) as a security mechanism. Unless
the filtering rules are designed to take source-specific routing into
account, they might be bypassed by a source-specific route, which
might cause traffic to reach a portion of a network that was thought
to be protected. Similarly, a network administrator might assume
that no route is more specific than a host route, and use a host
route in order to direct traffic for a given destination through a
security device (e.g., a firewall); source-specific routing
invalidates this assumption, and in some topologies announcing a
source-specific route might conceivably be used to bypass the
security device.
10. Acknowledgments 10. Acknowledgments
The authors are grateful to Donald Eastlake and Joel Halpern for The authors are grateful to Donald Eastlake and Joel Halpern for
their help with this document. their help with this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
skipping to change at page 10, line 46 skipping to change at page 11, line 11
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. DOI 10.17487/RFC2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017. May 2017.
11.2. Informative References 11.2. Informative References
[DSR] Lamparter, D. and A. Smirnov, "Destination/Source
Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing-
06, May 2018.
[RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
DOI 10.17487/RFC6126, April 2011, DOI 10.17487/RFC6126, April 2011,
<https://www.rfc-editor.org/info/rfc6126>. <https://www.rfc-editor.org/info/rfc6126>.
[SS-ROUTING] [SS-ROUTING]
Boutier, M. and J. Chroboczek, "Source-Specific Routing", Boutier, M. and J. Chroboczek, "Source-Specific Routing",
August 2014. August 2014.
In Proc. IFIP Networking 2015. A slightly earlier In Proc. IFIP Networking 2015. A slightly earlier
version is available online from http://arxiv.org/ version is available online from http://arxiv.org/
 End of changes. 17 change blocks. 
45 lines changed or deleted 52 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/