IPv6 over Link-Local Discovery Protocol
draft-richardson-anima-masa-considerations-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Michael Richardson | ||
| Last updated | 2019-12-03 | ||
| Stream | (None) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-richardson-anima-masa-considerations-00
anima Working Group M. Richardson
Internet-Draft Sandelman Software Works
Intended status: Standards Track December 03, 2019
Expires: June 5, 2020
IPv6 over Link-Local Discovery Protocol
draft-richardson-anima-masa-considerations-00
Abstract
This document describes a number of operational modes that a BRSKI
Manufacturer Authorized Signing Authority (MASA) may take on.
Each mode is defined, and then each mode is given a relevance within
an over applicability of what kind of organization the MASA is
deployed into. This document does not change any protocol
mechanisms.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 5, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Richardson Expires June 5, 2020 [Page 1]
Internet-Draft v6-LLDP December 2019
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. LLDP Encapsulation . . . . . . . . . . . . . . . . . . . 3
2.2. Content of Payload - option 1 - entire IPv6 packet . . . 4
2.3. Content of Payload - option 2 - elided IPv6 packet . . . 4
2.4. Content of Payload - option 3 - RFC8138 compressed packet 5
3. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The IEEE802.1AB Link Layer Discovery Protocol (LLDP) is a one-hop,
vendor-neutral link-layer protocol used by end host network Things
for advertising their identity, capabilities, and neighbors on an
IEEE 802 local area network.
Its Type-Length-Value (TLV) design allows for "vendor-specific"
extensions to be defined. IANA has a registered IEEE 802
organizationally unique identifier (OUI) defined as documented in
[RFC7042].
The creation and maintenance of the Autonomic Control Plane described
in [I-D.ietf-anima-autonomic-control-plane] requires creation of hop-
by-hop discovery of adjacent systems. There are Campus L2 systems
that are not broadcast safe until they have been connected to their
Software Defined Networking (SDN) controller.
The use of the stable connectivity provided by [RFC8368] can provide
the SDN connectivity required.
There is a bootstrap problem: the network may be unsafe for ACP
discovery broadcasts until configured, and it can not be
autonomically configured until the ACP discovery (and onboarding
process) is done.
Richardson Expires June 5, 2020 [Page 2]
Internet-Draft v6-LLDP December 2019
LLDP provides an out, as it is never broadcast, and it discovers all
compliant layer-2 devices in a network, even if they do not normally
do layer-3 forwarding.
Additional LLDP has the advantage that received LLDP frames are
already configured in routing fabrics to be send up to the control
plane processor, with information identifying which physical port it
was received on. This is exactly the desired data flow for the
[I-D.ietf-anima-autonomic-control-plane]: all traffic goes to the
control processor.
This document provides a way to transmit the IPv6 Link-Layer packets
that are needed for formation of the
[I-D.ietf-anima-autonomic-control-plane]. Those packets types
include: IPv6 Neighbor Discovery, GRASP DULL over IPv6 Link-Local,
IPsec ESP and IKEv2 packets.
2. Protocol
2.1. LLDP Encapsulation
The LLDP vendor-specific frame has the following format:
+--------+--------+----------+---------+--------------
|TLV Type| len | OUI |subtype | IPv6 fragment
| =127 | |= 00 00 5E| = TBD |
|(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets)
+--------+--------+----------+---------+--------------
where:
o TLV Type = 127 indicates a vendor-specific TLV
o len = indicates the TLV string length
o OUI = 00 00 5E is the organizationally unique identifier of IANA
o subtype = TBD (as assigned by IANA for this document)
o IPv6 fragment, up to 255 octets of packet.
The vendor-specific frame has a limit of 255 octets, while IPv6 has a
minimum MTU of 1280 bytes. An LLDP frame can contain more than one
TLV, and ethernet accomodates up to 1500 bytes (often larger), so it
should all fit.
Two possible solutions are discussed here:
Richardson Expires June 5, 2020 [Page 3]
Internet-Draft v6-LLDP December 2019
1. use six subtype TLV values. The first for 255 octets go into the
first TLV, the second 255 octets go into the second TLV, etc.
Six options of 255 bytes each results in a maximum payload size
of 1530, which exceeds the ethernet payload size. Given the
overhead of 6 bytes per TLV, plus other overhead, this results in
an MTU of 1450 bytes.
2. use the same TLV value, repeated six times.
The second method seems more obvious but it is unclear if all LLDP
subsystems would permit TLVs to be repeated, or if they would keep
the TLVs in the correct order. While the IANA has only 253 available
TLVs, and perhaps a request for 6 values might seem excessive, if
this resource was depleted, a new OUI could be used. Or an OUI
specific to this effort could be allocated.
2.2. Content of Payload - option 1 - entire IPv6 packet
The simplest encapsulation would put the entire IPv6 packet,
including the whole header in. This takes a bit more space, but
provides the maximum flexibility.
This flexibility may come at a cost of creating a new attack surface
for devices. Any L2 connected device may not inject IPv6 frames into
the control plane of the adjacenty router.
2.3. Content of Payload - option 2 - elided IPv6 packet
The [I-D.ietf-anima-autonomic-control-plane] use case only sends IPv6
Link-Local packets. The IPv6 source and destination address are
always directly related to the L2 Ethernet headers, with the use of
SLAAC derived IIDs, and the prefix "fe80".
This proposal is to include only the fields: 1. Payload Length 2.
Next Header
The Hop Limit is always 1 for Link-Local packets. The Flow Label is
always 0.
Note that in the [I-D.ietf-anima-autonomic-control-plane] a mesh of
IPsec tunnels is created on top of ESP packets over IPv6 Link-Local,
and within that tunnel all of IPv6 can be sent.
The use hard coding of so many values significantly limits the attack
surface possible.
Richardson Expires June 5, 2020 [Page 4]
Internet-Draft v6-LLDP December 2019
2.4. Content of Payload - option 3 - RFC8138 compressed packet
An option similar to above, yet providing a bit more flexibility is
to use [RFC8138] compression of packets as it done on low powered
802.15.4 networks.
This results in compression that is close to what option 2 provides,
yet provides for a lot of flexibility.
This option requires more code, may be subject to new attacks on the
decompression code, and expands the attack surface to all of IPv6, as
well as the RFC8138 compression code.
3. Privacy Considerations
YYY
4. Security Considerations
ZZZ
5. IANA Considerations
6. Acknowledgements
Hello.
7. Changelog
8. References
8.1. Normative References
[I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-21 (work in progress), November 2019.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
October 2013, <https://www.rfc-editor.org/info/rfc7042>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
Richardson Expires June 5, 2020 [Page 5]
Internet-Draft v6-LLDP December 2019
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.
[RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic
Control Plane for Stable Connectivity of Network
Operations, Administration, and Maintenance (OAM)",
RFC 8368, DOI 10.17487/RFC8368, May 2018,
<https://www.rfc-editor.org/info/rfc8368>.
Author's Address
Michael Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
Richardson Expires June 5, 2020 [Page 6]