draft-ietf-babel-rfc6126bis-06.txt   draft-ietf-babel-rfc6126bis-07.txt 
Network Working Group J. Chroboczek Network Working Group J. Chroboczek
Internet-Draft IRIF, University of Paris-Diderot Internet-Draft IRIF, University of Paris-Diderot
Obsoletes: 6126,7557 (if approved) D. Schinazi Obsoletes: 6126,7557 (if approved) D. Schinazi
Intended status: Standards Track Apple Inc. Intended status: Standards Track Google LLC
Expires: April 26, 2019 October 23, 2018 Expires: May 18, 2019 November 14, 2018
The Babel Routing Protocol The Babel Routing Protocol
draft-ietf-babel-rfc6126bis-06 draft-ietf-babel-rfc6126bis-07
Abstract Abstract
Babel is a loop-avoiding distance-vector routing protocol that is Babel is a loop-avoiding distance-vector routing protocol that is
robust and efficient both in ordinary wired networks and in wireless robust and efficient both in ordinary wired networks and in wireless
mesh networks. This document describes the Babel routing protocol, mesh networks. This document describes the Babel routing protocol,
and obsoletes RFCs 6126 and 7557 and obsoletes RFCs 6126 and 7557
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 April 26, 2019. This Internet-Draft will expire on May 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 2, line 43 skipping to change at page 2, line 43
4.4. Sub-TLV Format . . . . . . . . . . . . . . . . . . . . . 34 4.4. Sub-TLV Format . . . . . . . . . . . . . . . . . . . . . 34
4.5. Parser state . . . . . . . . . . . . . . . . . . . . . . 35 4.5. Parser state . . . . . . . . . . . . . . . . . . . . . . 35
4.6. Details of Specific TLVs . . . . . . . . . . . . . . . . 36 4.6. Details of Specific TLVs . . . . . . . . . . . . . . . . 36
4.7. Details of specific sub-TLVs . . . . . . . . . . . . . . 46 4.7. Details of specific sub-TLVs . . . . . . . . . . . . . . 46
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
6. Security Considerations . . . . . . . . . . . . . . . . . . . 48 6. Security Considerations . . . . . . . . . . . . . . . . . . . 48
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.1. Normative References . . . . . . . . . . . . . . . . . . 49 8.1. Normative References . . . . . . . . . . . . . . . . . . 49
8.2. Informative References . . . . . . . . . . . . . . . . . 50 8.2. Informative References . . . . . . . . . . . . . . . . . 50
Appendix A. Cost and Metric Computation . . . . . . . . . . . . 50 Appendix A. Cost and Metric Computation . . . . . . . . . . . . 51
A.1. Maintaining Hello History . . . . . . . . . . . . . . . . 51 A.1. Maintaining Hello History . . . . . . . . . . . . . . . . 51
A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 52 A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . 52
A.3. Metric Computation . . . . . . . . . . . . . . . . . . . 53 A.3. Metric Computation . . . . . . . . . . . . . . . . . . . 53
Appendix B. Constants . . . . . . . . . . . . . . . . . . . . . 54 Appendix B. Constants . . . . . . . . . . . . . . . . . . . . . 54
Appendix C. Considerations for protocol extensions . . . . . . . 55 Appendix C. Considerations for protocol extensions . . . . . . . 55
Appendix D. Stub Implementations . . . . . . . . . . . . . . . . 56 Appendix D. Stub Implementations . . . . . . . . . . . . . . . . 57
Appendix E. Software Availability . . . . . . . . . . . . . . . 57 Appendix E. Software Availability . . . . . . . . . . . . . . . 57
Appendix F. Changes from previous versions . . . . . . . . . . . 57 Appendix F. Changes from previous versions . . . . . . . . . . . 58
F.1. Changes since RFC 6126 . . . . . . . . . . . . . . . . . 57 F.1. Changes since RFC 6126 . . . . . . . . . . . . . . . . . 58
F.2. Changes since draft-ietf-babel-rfc6126bis-00 . . . . . . 58 F.2. Changes since draft-ietf-babel-rfc6126bis-00 . . . . . . 58
F.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 58 F.3. Changes since draft-ietf-babel-rfc6126bis-01 . . . . . . 58
F.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 58 F.4. Changes since draft-ietf-babel-rfc6126bis-02 . . . . . . 59
F.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 59 F.5. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 59
F.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 59 F.6. Changes since draft-ietf-babel-rfc6126bis-03 . . . . . . 60
F.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 59 F.7. Changes since draft-ietf-babel-rfc6126bis-04 . . . . . . 60
F.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 60 F.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 60
F.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Introduction 1. Introduction
Babel is a loop-avoiding distance-vector routing protocol that is Babel is a loop-avoiding distance-vector routing protocol that is
designed to be robust and efficient both in networks using prefix- designed to be robust and efficient both in networks using prefix-
based routing and in networks using flat routing ("mesh networks"), based routing and in networks using flat routing ("mesh networks"),
and both in relatively stable wired networks and in highly dynamic and both in relatively stable wired networks and in highly dynamic
wireless networks. wireless networks.
skipping to change at page 33, line 45 skipping to change at page 33, line 45
silently ignored. silently ignored.
Body length The length in octets of the body following the packet Body length The length in octets of the body following the packet
header (excluding the Magic, Version and Body length header (excluding the Magic, Version and Body length
fields, and excluding the packet trailer). fields, and excluding the packet trailer).
Packet Body The packet body; a sequence of TLVs. Packet Body The packet body; a sequence of TLVs.
Packet Trailer The packet trailer; another sequence of TLVs. Packet Trailer The packet trailer; another sequence of TLVs.
The packet body and the packet trailer are both sequences of TLVs. A The packet body and trailer are both sequences of TLVs. The packet
TLV may appear in the packet trailer only if it is explicitly allowed body is the normal place to store TLVs; the packet trailer only
to do so: the receiver MUST silently ignore any TLV that appears in contains specialised TLVs that do not need to be protected by
the packet trailer unless it is explicitly specified to be allowed in cryptographic security mechanisms. When parsing the trailer, the
the packet trailer. Among the TLVs defined in this document, only receiver MUST ignore any TLV unless its definition explicitly states
Pad1 and PadN are allowed in the packet trailer; since these TLVs are that it is allowed to appear there. Among the TLVs defined in this
ignored in any case, an implementation MAY silently ignore the packet document, only Pad1 and PadN are allowed in the trailer; since these
trailer unless it implements at least one extension that uses the TLVs are ignored in any case, an implementation MAY silently ignore
packet trailer. the packet trailer without even parsing it, unless it implements at
least one extension that defines TLVs that are allowed to appear in
the trailer.
4.3. TLV Format 4.3. TLV Format
With the exception of Pad1, all TLVs have the following structure: With the exception of Pad1, all TLVs have the following structure:
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 | Length | Payload... | Type | Length | Payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
skipping to change at page 48, line 34 skipping to change at page 48, line 34
range 2 to 111 are not changed by this specification. The values 224 range 2 to 111 are not changed by this specification. The values 224
through 239, previously reserved for Experimental Use, are now through 239, previously reserved for Experimental Use, are now
unassigned. unassigned.
IANA has created a registry called "Babel Flags Values". IANA is IANA has created a registry called "Babel Flags Values". IANA is
instructed to rename this registry to "Babel Update Flags Values", instructed to rename this registry to "Babel Update Flags Values",
with its contents unchanged. with its contents unchanged.
IANA is instructed to create a new registry called "Babel Hello Flags IANA is instructed to create a new registry called "Babel Hello Flags
Values". The allocation policy for this registry is Specification Values". The allocation policy for this registry is Specification
Required [RFC5226]. The initial values in this registry are as Required [RFC8126]. The initial values in this registry are as
follows: follows:
+------+------------+---------------+ +------+------------+---------------+
| Bit | Name | Reference | | Bit | Name | Reference |
+------+------------+---------------+ +------+------------+---------------+
| 0 | Unicast | this document | | 0 | Unicast | this document |
| | | | | | | |
| 1-15 | Unassigned | | | 1-15 | Unassigned | |
+------+------------+---------------+ +------+------------+---------------+
IANA is instructed to replace all references to RFCs 6126 and 7557 in IANA is instructed to replace all references to RFCs 6126 and 7557 in
all of the registries mentioned above by references to this document. all of the registries mentioned above by references to this document.
6. Security Considerations 6. Security Considerations
As defined in this document, Babel is a completely insecure protocol. As defined in this document, Babel is a completely insecure protocol.
Any attacker can misdirect data traffic by advertising routes with a Any attacker can misdirect data traffic by advertising routes with a
low metric or a high seqno. This issue can be solved either by a low metric or a high seqno. This issue can be solved either by a
lower-layer security mechanism (e.g., link-layer security), or by lower-layer security mechanism (e.g., link-layer security or IPsec),
deploying a suitable authentication mechanism within Babel itself. or by deploying a suitable authentication mechanism within Babel
With the exception of Hello TLVs used for discovery, Babel control itself. There are currently two such mechanisms: Babel over DTLS
traffic can be carried over unicast, which makes it possible to [BABEL-DTLS] and HMAC-based authentication [BABEL-HMAC]. Both
protect Babel traffic with a protocol that can only protect unicast mechanisms ensure integrity of messages and prevent message replay,
data, for example IPsec with IKEv2, or DTLS. but only DTLS supports asymmetric keying and message confidentiality.
HMAC is simpler and does not depend on DTLS, and therefore its use is
RECOMMENDED whenever both mechanisms are applicable.
The information that a Babel node announces to the whole routing The information that a Babel node announces to the whole routing
domain is often sufficient to determine a mobile node's physical domain is often sufficient to determine a mobile node's physical
location with reasonable precision. The privacy issues that this location with reasonable precision. The privacy issues that this
causes can be mitigated somewhat by using randomly chosen router-ids causes can be mitigated somewhat by using randomly chosen router-ids
and randomly chosen IP addresses, and changing them periodically. and randomly chosen IP addresses, and changing them periodically.
When carried over IPv6, Babel packets are ignored unless they are When carried over IPv6, Babel packets are ignored unless they are
sent from a link-local IPv6 address; since routers don't forward sent from a link-local IPv6 address; since routers don't forward
link-local IPv6 packets, this provides protection against spoofed link-local IPv6 packets, this provides protection against spoofed
skipping to change at page 49, line 36 skipping to change at page 49, line 38
specification. The authors are particularly indebted to Matthieu specification. The authors are particularly indebted to Matthieu
Boutier, Gwendoline Chouasne, Margaret Cullen, Donald Eastlake and Boutier, Gwendoline Chouasne, Margaret Cullen, Donald Eastlake and
Toke Hoiland-Jorgensen. Earlier versions of this document greatly Toke Hoiland-Jorgensen. Earlier versions of this document greatly
benefited from the input of Joel Halpern. The address compression benefited from the input of Joel Halpern. The address compression
technique was inspired by [PACKETBB]. technique was inspired by [PACKETBB].
8. References 8. References
8.1. Normative References 8.1. Normative References
[BABEL-DTLS]
Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
Routing Protocol over Datagram Transport Layer Security",
Internet Draft draft-ietf-babel-dtls-01, October 2018.
[BABEL-HMAC]
Do, C., Kolodziejak, W., and J. Chroboczek, "HMAC
authentication for the Babel routing protocol", Internet
Draft draft-ietf-babel-hmac-01, November 2018.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
IANA Considerations Section in RFCs", BCP 26, RFC 5226, Writing an IANA Considerations Section in RFCs", BCP 26,
May 2008. RFC 8126, June 2017.
[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.
8.2. Informative References 8.2. Informative References
[DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination-
Sequenced Distance-Vector Routing (DSDV) for Mobile Sequenced Distance-Vector Routing (DSDV) for Mobile
Computers", ACM SIGCOMM'94 Conference on Communications Computers", ACM SIGCOMM'94 Conference on Communications
skipping to change at page 56, line 32 skipping to change at page 56, line 44
compatibility is required. A similar issue arises with Update TLVs compatibility is required. A similar issue arises with Update TLVs
with unknown AEs establishing a new router-id (due to the Router-Id with unknown AEs establishing a new router-id (due to the Router-Id
flag being set). Therefore, defining new AEs must be done with care flag being set). Therefore, defining new AEs must be done with care
if compatibility with unextended implementations is required. if compatibility with unextended implementations is required.
The packet trailer is intended to carry cryptographic signatures that The packet trailer is intended to carry cryptographic signatures that
only cover the packet body; storing the cryptographic signatures in only cover the packet body; storing the cryptographic signatures in
the packet trailer avoids clearing the signature before computing a the packet trailer avoids clearing the signature before computing a
hash of the packet body, and makes it possible to check a hash of the packet body, and makes it possible to check a
cryptographic signature before running the full, stateful TLV parser. cryptographic signature before running the full, stateful TLV parser.
Thus, any TLV that is allowed to appear in the packet trailer must Hence, only TLVs that don't need to be protected by cryptographic
not need to be protected by cryptographic security protocols, it security protocols should be allowed in the packet trailer. Any such
should be easy to parse, and should not require stateful parsing. TLVs should be easy to parse, and in particular should not require
stateful parsing.
Appendix D. Stub Implementations Appendix D. Stub Implementations
Babel is a fairly economic protocol. Updates take between 12 and 40 Babel is a fairly economic protocol. Updates take between 12 and 40
octets per destination, depending on the address family and how octets per destination, depending on the address family and how
successful compression is; in a double-stack flat network, an average successful compression is; in a double-stack flat network, an average
of less than 24 octets per update is typical. The route table of less than 24 octets per update is typical. The route table
occupies about 35 octets per IPv6 entry. To put these values into occupies about 35 octets per IPv6 entry. To put these values into
perspective, a single full-size Ethernet frame can carry some 65 perspective, a single full-size Ethernet frame can carry some 65
route updates, and a megabyte of memory can contain a 20000-entry route updates, and a megabyte of memory can contain a 20000-entry
skipping to change at page 60, line 10 skipping to change at page 60, line 26
o Updated requirements boilerplate to RFC 8174. o Updated requirements boilerplate to RFC 8174.
o Minor editorial changes. o Minor editorial changes.
F.8. Changes since draft-ietf-babel-rfc6126bis-05 F.8. Changes since draft-ietf-babel-rfc6126bis-05
o Added information about the packet trailer, now that it is used by o Added information about the packet trailer, now that it is used by
draft-ietf-babel-hmac. draft-ietf-babel-hmac.
F.9. Changes since draft-ietf-babel-rfc6126bis-06
o Added references to security documents.
Authors' Addresses Authors' Addresses
Juliusz Chroboczek Juliusz Chroboczek
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
Case 7014 Case 7014
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: jch@irif.fr Email: jch@irif.fr
David Schinazi David Schinazi
Apple Inc. Google LLC
1 Infinite Loop 1600 Amphitheatre Parkway
Cupertino, California 95014 Mountain View, California 94043
US USA
Email: dschinazi@apple.com Email: dschinazi.ietf@gmail.com
 End of changes. 18 change blocks. 
37 lines changed or deleted 57 lines changed or added

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