draft-ietf-6lo-backbone-router-19.txt   draft-ietf-6lo-backbone-router-20.txt 
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6775, 8505 (if approved) C.E. Perkins Updates: 6775, 8505 (if approved) C.E. Perkins
Intended status: Standards Track Blue Meadow Networking Intended status: Standards Track Blue Meadow Networking
Expires: 4 September 2020 E. Levy-Abegnoli Expires: 24 September 2020 E. Levy-Abegnoli
Cisco Systems Cisco Systems
3 March 2020 23 March 2020
IPv6 Backbone Router IPv6 Backbone Router
draft-ietf-6lo-backbone-router-19 draft-ietf-6lo-backbone-router-20
Abstract Abstract
This document updates RFC 6775 and RFC 8505 in order to enable proxy This document updates RFC 6775 and RFC 8505 in order to enable proxy
services for IPv6 Neighbor Discovery by Routing Registrars called services for IPv6 Neighbor Discovery by Routing Registrars called
Backbone Routers. Backbone Routers are placed along the wireless Backbone Routers. Backbone Routers are placed along the wireless
edge of a Backbone, and federate multiple wireless links to form a edge of a Backbone, and federate multiple wireless links to form a
single Multi-Link Subnet. single Multi-Link Subnet.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 4 September 2020. This Internet-Draft will expire on 24 September 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 33 skipping to change at page 2, line 33
5. Optional 6LBR serving the Multi-Link Subnet . . . . . . . . . 17 5. Optional 6LBR serving the Multi-Link Subnet . . . . . . . . . 17
6. Using IPv6 ND Over the Backbone Link . . . . . . . . . . . . 18 6. Using IPv6 ND Over the Backbone Link . . . . . . . . . . . . 18
7. Routing Proxy Operations . . . . . . . . . . . . . . . . . . 20 7. Routing Proxy Operations . . . . . . . . . . . . . . . . . . 20
8. Bridging Proxy Operations . . . . . . . . . . . . . . . . . . 21 8. Bridging Proxy Operations . . . . . . . . . . . . . . . . . . 21
9. Creating and Maintaining a Binding . . . . . . . . . . . . . 22 9. Creating and Maintaining a Binding . . . . . . . . . . . . . 22
9.1. Operations on a Binding in Tentative State . . . . . . . 23 9.1. Operations on a Binding in Tentative State . . . . . . . 23
9.2. Operations on a Binding in Reachable State . . . . . . . 24 9.2. Operations on a Binding in Reachable State . . . . . . . 24
9.3. Operations on a Binding in Stale State . . . . . . . . . 25 9.3. Operations on a Binding in Stale State . . . . . . . . . 25
10. Registering Node Considerations . . . . . . . . . . . . . . . 26 10. Registering Node Considerations . . . . . . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 29 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 30
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
15. Normative References . . . . . . . . . . . . . . . . . . . . 30 15. Normative References . . . . . . . . . . . . . . . . . . . . 30
16. Informative References . . . . . . . . . . . . . . . . . . . 31 16. Informative References . . . . . . . . . . . . . . . . . . . 32
Appendix A. Possible Future Extensions . . . . . . . . . . . . . 34 Appendix A. Possible Future Extensions . . . . . . . . . . . . . 34
Appendix B. Applicability and Requirements Served . . . . . . . 35 Appendix B. Applicability and Requirements Served . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient
and reliable broadcast service for wired networks; applications and and reliable broadcast service for wired networks; applications and
protocols have been built that heavily depend on that feature for protocols have been built that heavily depend on that feature for
their core operation. Unfortunately, Low-Power Lossy Networks (LLNs) their core operation. Unfortunately, Low-Power Lossy Networks (LLNs)
and local wireless networks generally do not provide the broadcast and local wireless networks generally do not provide the broadcast
capabilities of Ethernet Bridging in an economical fashion. capabilities of Ethernet Bridging in an economical fashion.
skipping to change at page 7, line 37 skipping to change at page 7, line 37
"IPv6 Stateless Address Autoconfiguration" [RFC4862] and "IPv6 Stateless Address Autoconfiguration" [RFC4862] and
"Optimistic Duplicate Address Detection" [RFC4429], "Optimistic Duplicate Address Detection" [RFC4429],
IPv6 ND over multiple links: "Neighbor Discovery Proxies (proxy-ND)" IPv6 ND over multiple links: "Neighbor Discovery Proxies (proxy-ND)"
[RFC4389] and "Multi-Link Subnet Issues" [RFC4903], [RFC4389] and "Multi-Link Subnet Issues" [RFC4903],
6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power 6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], and Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], and
6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy 6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy
Networks [RFC6775] and "Registration Extensions for 6LoWPAN Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor
Neighbor Discovery" [RFC8505]. Discovery" [RFC8505], and " Address Protected Neighbor Discovery
for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd].
3. Overview 3. Overview
This section and its subsections present a non-normative high level This section and its subsections present a non-normative high level
view of the operation of the 6BBR. The following sections cover the view of the operation of the 6BBR. The following sections cover the
normative part. Figure 1 illustrates a backbone link that federates normative part.
a collection of LLNs as a single IPv6 Subnet, with a number of 6BBRs
providing proxy-ND services to their attached LLNs. Figure 1 illustrates a backbone link that federates a collection of
LLNs as a single IPv6 Subnet, with a number of 6BBRs providing proxy-
ND services to their attached LLNs.
| |
+-----+ +-----+ +-----+ IPv6 +-----+ +-----+ +-----+ IPv6
(default) | | (Optional) | | | | Node (default) | | (Optional) | | | | Node
Router | | 6LBR | | | | or Router | | 6LBR | | | | or
+-----+ +-----+ +-----+ 6LN +-----+ +-----+ +-----+ 6LN
| Backbone side | | | Backbone side | |
----+-------+-----------------+---+-------------+----+----- ----+-------+-----------------+---+-------------+----+-----
| | | | | |
+------+ +------+ +------+ +------+ +------+ +------+
skipping to change at page 27, line 19 skipping to change at page 27, line 19
The Registering Node SHOULD also follow BCP 202 [RFC7772] in order to The Registering Node SHOULD also follow BCP 202 [RFC7772] in order to
limit the use of multicast RAs. It SHOULD also implement Simple limit the use of multicast RAs. It SHOULD also implement Simple
Procedures for Detecting Network Attachment in IPv6 [RFC6059] (DNA Procedures for Detecting Network Attachment in IPv6 [RFC6059] (DNA
procedures) to detect movements, and support Packet-Loss Resiliency procedures) to detect movements, and support Packet-Loss Resiliency
for Router Solicitations [RFC7559] in order to improve reliability for Router Solicitations [RFC7559] in order to improve reliability
for the unicast RS messages. for the unicast RS messages.
11. Security Considerations 11. Security Considerations
The procedures in this document modify the mechanisms used for IPv6
ND and DAD and should not affect other aspects of IPv6 or higher-
level-protocol operation. As such, the main classes of attacks that
are in play are those which week to block neighbor discovery or to
forcibly claim an address that another node is attempting to use. In
the absence of cryptographic protection at higher layers, the latter
class of attacks can have significant consequences, with the attacker
being able to read all the "stolen" traffic that was directed to the
target of the attack.
This specification applies to LLNs and a backbone in which the This specification applies to LLNs and a backbone in which the
individual links are protected against rogue access, by individual links are protected against rogue access, on the LLN by
authenticating a node that attaches to the network and encrypting at authenticating a node that attaches to the network and encrypting at
the MAC layer the transmissions so packets may neither be overheard the MAC layer the transmissions, and on the backbone side using the
or nor forged. In particular, the LLN MAC is required to provide physical security and access control measures that are typically
secure unicast to/from the Backbone Router and secure broadcast from applied there, so packets may neither be forged or nor overheard.
the routers in a way that prevents tampering with or replaying the ND
messages. In particular, the LLN MAC is required to provide secure unicast to/
from the Backbone Router and secure broadcast from the routers in a
way that prevents tampering with or replaying the ND messages.
For the IPv6 ND operation over the backbone, and unless the classical For the IPv6 ND operation over the backbone, and unless the classical
ND is disabled (e.g., by configuration), the classical ND messages ND is disabled (e.g., by configuration), the classical ND messages
are interpreted as emitted by the address owner and have precedence are interpreted as emitted by the address owner and have precedence
over the 6BBR that is only a proxy. It results that the security over the 6BBR that is only a proxy.
threats that are detailed in section 11.1 of [RFC4861] fully apply to
this specification as well. In very short: It results that the security threats that are detailed in section
11.1 of [RFC4861] fully apply to this specification as well. In very
short:
* Any node that can send a packet on the backbone can take over any * Any node that can send a packet on the backbone can take over any
address including addresses of LLN nodes by claiming it with an NA address including addresses of LLN nodes by claiming it with an NA
message and the Override bit set. This means that the real owner message and the Override bit set. This means that the real owner
will stop receiving its packets. will stop receiving its packets.
* Any node that can send a packet on the backbone can forge traffic * Any node that can send a packet on the backbone can forge traffic
and pretend it is issued from a address that it does not own, even and pretend it is issued from a address that it does not own, even
if it did not claim the address using ND. if it did not claim the address using ND.
skipping to change at page 28, line 11 skipping to change at page 28, line 24
* If the rogue can receive a packet from the backbone it can also * If the rogue can receive a packet from the backbone it can also
snoop all the intercepted traffic, be it by stealing an address or snoop all the intercepted traffic, be it by stealing an address or
the role of a router. the role of a router.
This means that any rogue access to the backbone must be prevented at This means that any rogue access to the backbone must be prevented at
all times, and that nodes that are attached to the backbone must be all times, and that nodes that are attached to the backbone must be
fully trusted / never compromised. fully trusted / never compromised.
Using address registration as the sole ND mechanism on a link and Using address registration as the sole ND mechanism on a link and
coupling it with [I-D.ietf-6lo-ap-nd] guarantees the ownership of a coupling it with [I-D.ietf-6lo-ap-nd] guarantees the ownership of a
registered address within that link. The protection is based on a registered address within that link.
proof-of-ownership encoded in the ROVR field and protects against
address theft and impersonation by a 6LN, because the 6LR can
challenge the Registered Node for a proof-of-ownership.
The protection extends to the full LLN in the case of an LLN Link, * The protection is based on a proof-of-ownership encoded in the
but does not extend over the backbone since the 6BBR cannot provide ROVR field and protects against address theft and impersonation by
the proof-of-ownership when it defends the address. a 6LN, because the 6LR can challenge the Registered Node for a
proof-of-ownership.
* The protection extends to the full LLN in the case of an LLN Link,
but does not extend over the backbone since the 6BBR cannot
provide the proof-of-ownership when it defends the address.
A possible attack over the backbone can be done by sending an NS with A possible attack over the backbone can be done by sending an NS with
an EARO and expecting the NA(EARO) back to contain the TID and ROVR an EARO and expecting the NA(EARO) back to contain the TID and ROVR
fields of the existing state. With that information, the attacker fields of the existing state. With that information, the attacker
can easily increase the TID and take over the Binding. can easily increase the TID and take over the Binding.
If the classical ND is disabled on the backbone and the use of If the classical ND is disabled on the backbone and the use of
[I-D.ietf-6lo-ap-nd] and a 6LBR are mandated, the network will [I-D.ietf-6lo-ap-nd] and a 6LBR are mandated, the network will
benefit from the following new advantages: benefit from the following new advantages:
skipping to change at page 29, line 15 skipping to change at page 29, line 30
Less Layer-2 churn on the backbone: Using the Routing Proxy Less Layer-2 churn on the backbone: Using the Routing Proxy
approach, the Link-Layer address of the LLN devices and their approach, the Link-Layer address of the LLN devices and their
mobility are not visible in the backbone; only the Link-Layer mobility are not visible in the backbone; only the Link-Layer
addresses of the 6BBR and backbone nodes are visible at Layer 2 on addresses of the 6BBR and backbone nodes are visible at Layer 2 on
the backbone. This is mandatory for LLNs that cannot be bridged the backbone. This is mandatory for LLNs that cannot be bridged
on the backbone, and useful in any case to scale down, stabilize on the backbone, and useful in any case to scale down, stabilize
the forwarding tables at Layer 2 and avoid the gratuitous frames the forwarding tables at Layer 2 and avoid the gratuitous frames
that are typically broadcasted to fix the transparent bridging that are typically broadcasted to fix the transparent bridging
tables when a wireless node roams from an AP to the next. tables when a wireless node roams from an AP to the next.
This specification introduce a 6BBR that is a router on the path of This specification introduces a 6BBR that is a router on the path of
the LLN traffic and a 6LBR that is used for the lookup. They could the LLN traffic and a 6LBR that is used for the lookup. They could
be interesting targets for an attacker, but not more than a default be interesting targets for an attacker. A compromised 6BBR can
router and a DHCP server, respectively, which already exist in accept a registration but block the traffic, or refrain from
classical networks, and can be defended using the same methods. proxying. A compromised 6LBR may accept unduly the transfer of
ownership of an address, or block a new comer by faking that its
address is a duplicate. But those attacks are possible in a
classical network from a compromised default router and a DHCP
server, respectively, and can be prevented using the same methods.
A possible attack over the LLN can still be done by compromising a A possible attack over the LLN can still be done by compromising a
6LR. A compromised 6LR may modify the ROVR of EDAR messages in 6LR. A compromised 6LR may modify the ROVR of EDAR messages in
flight and transfer the ownership of the Registered Address to itself flight and transfer the ownership of the Registered Address to itself
or a tier. It may also claim that a ROVR was validated when it or a tier. It may also claim that a ROVR was validated when it
really wasn't, and reattribute an address to self or to an attached really wasn't, and reattribute an address to self or to an attached
6LN. This means that 6LRs, as well as 6LBRs and 6BBRS must still be 6LN. This means that 6LRs, as well as 6LBRs and 6BBRS must still be
fully trusted / never compromised. fully trusted / never compromised.
This specification mandates to check on the 6LBR on the backbone This specification mandates to check on the 6LBR on the backbone
skipping to change at page 30, line 15 skipping to change at page 30, line 31
13. IANA Considerations 13. IANA Considerations
This document has no request to IANA. This document has no request to IANA.
14. Acknowledgments 14. Acknowledgments
Many thanks to Dorothy Stanley, Thomas Watteyne and Jerome Henry for Many thanks to Dorothy Stanley, Thomas Watteyne and Jerome Henry for
their various contributions. Also many thanks to Timothy Winters and their various contributions. Also many thanks to Timothy Winters and
Erik Nordmark for their help, review and support in preparation to Erik Nordmark for their help, review and support in preparation to
the IESG cycle, and to Kyle Rose, Elwyn Davies, Barry Leiba, Mirja the IESG cycle, and to Kyle Rose, Elwyn Davies, Barry Leiba, Mirja
Kühlewind, Alvaro Retana, Roman Danyliw and very especially Kuhlewind, Alvaro Retana, Roman Danyliw and very especially Dominique
Dominique Barthel and Benjamin Kaduk for their useful contributions Barthel and Benjamin Kaduk for their useful contributions through the
through the IETF last call and IESG process. IETF last call and IESG process.
15. Normative References 15. Normative References
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
skipping to change at page 33, line 18 skipping to change at page 33, line 34
Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6
Neighbor Discovery Optional RS/RA Refresh", Work in Neighbor Discovery Optional RS/RA Refresh", Work in
Progress, Internet-Draft, draft-ietf-6man-rs-refresh-02, Progress, Internet-Draft, draft-ietf-6man-rs-refresh-02,
31 October 2016, <https://tools.ietf.org/html/draft-ietf- 31 October 2016, <https://tools.ietf.org/html/draft-ietf-
6man-rs-refresh-02>. 6man-rs-refresh-02>.
[I-D.ietf-6lo-ap-nd] [I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and "Address Protected Neighbor Discovery for Low-power and
Lossy Networks", Work in Progress, Internet-Draft, draft- Lossy Networks", Work in Progress, Internet-Draft, draft-
ietf-6lo-ap-nd-19, 6 February 2020, ietf-6lo-ap-nd-20, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-19>. <https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-20>.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", Work in Progress, Internet-Draft, of IEEE 802.15.4", Work in Progress, Internet-Draft,
draft-ietf-6tisch-architecture-28, 29 October 2019, draft-ietf-6tisch-architecture-28, 29 October 2019,
<https://tools.ietf.org/html/draft-ietf-6tisch- <https://tools.ietf.org/html/draft-ietf-6tisch-
architecture-28>. architecture-28>.
[I-D.ietf-mboned-ieee802-mcast-problems] [I-D.ietf-mboned-ieee802-mcast-problems]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
 End of changes. 19 change blocks. 
37 lines changed or deleted 60 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/