Internet DRAFT - draft-herbert-simple-sr
draft-herbert-simple-sr
INTERNET-DRAFT T. Herbert
Intended Status: Standard Quantonium
Expires: September 2019
March 11, 2019
Simple Segment Routing Header
draft-herbert-simple-sr-00
Abstract
This specification defines a simple extension header format for
Segment Routing based on the current definition of the Segment
Routing extension header defined for IPv6. A Segment Identifier type
field is added so that the segment list might contain values other
than IPv6 addresses. Optional TLVs in the segment routing header are
eliminated; Destination options that precede the routing header are
sufficient. Two new destination options are defined: one for Routing
header security and another to specify that certain destinations
should process certain options.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
T. Herbert Expires September 12, 2019 [Page 1]
INTERNET DRAFT draft-herbert-simple-sr-00 March 11, 2019
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Simple segment routing header format . . . . . . . . . . . . . 4
2.1 SType values . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Routing header security option . . . . . . . . . . . . . . . . 5
3.1 HMAC Routing header security . . . . . . . . . . . . . . . . 7
3.2 Operation . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1 Sender operation . . . . . . . . . . . . . . . . . . . . 7
3.2.2 Receiver operation . . . . . . . . . . . . . . . . . . . 7
4 Process per segment Destination Option . . . . . . . . . . . . 8
4.1 Sender operation . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Receiver operation . . . . . . . . . . . . . . . . . . . . . 9
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 10
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Normative References . . . . . . . . . . . . . . . . . . . 10
7.2 Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
T. Herbert Expires September 12, 2019 [Page 2]
INTERNET DRAFT draft-herbert-simple-sr-00 March 11, 2019
1 Introduction
This specification defines a simplified segment routing header and
generalizes some aspects of segment routing to be applicable to other
types of routing headers. The segment routing header is defined in
[SRHV6].
The following modifications and additions are defined:
* A Segment Identifier type field in the Segment routing header.
This field indicates the type of elements in the segment routing
list and also indicates the length of each element. Segment
Identifier types are defined for IPv6 and IPv4 addresses, as
well as types for indices into tables that would map a Segment
Identifier to an address. The concept of types for Segment
Identifier is a generalization of Segment Routing header
compression defined in [SRCOMP].
* Eliminate options (TLVs) from Segment Routing header.
Options pertaining to Segment Routing, or more generally any
type of Routing header, may be set in Destination Options that
precede the Routing header.
* Routing header security Destination option.
This option provides an extensible method for verifying security
of a routing header. An HMAC option is defined that provides the
same functionality as the HMAC TLV defined in [SRV6EH] (except
that it is generic to work with all types of Routing headers).
* Process per segment Destination option.
The purpose of this option is to allow a node to indicate that
certain Destination options are to be processed only by certain
nodes in the Segment List. This is a generalization of the
option described in [SRENDOPT].
T. Herbert Expires September 12, 2019 [Page 3]
INTERNET DRAFT draft-herbert-simple-sr-00 March 11, 2019
2 Simple segment routing header format
The format of the simple segment routing header is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | SType | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Segment List[0] (length per Stype) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
...
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Segment List[n] (length per SType) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format is based on that described in [SRV6EH]. Modified or added
fields are:
o SType: Type of segment identifiers. Possible values are listed
below.
o Segment List[]. Each element of the segment list contains a
segment identifier with the type indicated by SType. The length
of each identifier is implied by the SType.
Note that the optional TLVs section is not present in the simplified
format. The rest of the fields in the format retain the same meaning
an format as described in [SRV6EH].
2.1 SType values
The following are the SType values:
o 0: IPv6 address, 128 bit value
o 1: IPv6 identifier, 64 bit value
T. Herbert Expires September 12, 2019 [Page 4]
INTERNET DRAFT draft-herbert-simple-sr-00 March 11, 2019
o 2: IPv6 locator, 64 bit value
o 3: IPv4 address, 32 bit value
o 4: 8 bit map value
o 5: 16 bit map value
o 6: 32 bit map value
o 7: 64 bit map value
Values 8 to 13 are reserved. Values 14 and 15 are experimental and
may be specified locally in a segment routing domain.
The IPv6 identifier provides the low order 64 bits of IPv6 address.
The high order 64 bit prefix is assumed to be common for all
destinations. A fully qualified IPv6 address is created by combing
the upper 64 bit prefix in the destination address of the packet with
the identifier value as the low order 64 bits. The identifier type
can be considered of form of compressing IPv6 addresses in segment
identifiers when all the segment identifiers share the same prefix
(.e.g a sixty-four bit prefix is common for all addresses in a
segment routing domain.
The IPv6 locator provides the high order 64 bits of IPv6 address. The
low order 64 bits are assumed to be common for all destinations in a
segment routing list. The use case for this would be
Identifier/Locator protocols such as ILA or ILNP. A fully qualified
address is created by combining the 64 bit prefix in the destination
address of the packet with the identifier value as the low order 64
bits. The locatorr type can be considered of form of compressing IPv6
addresses in segment identifiers when all the segment identifiers
share the same low order sixty-four bits.
Map values are mapped by receivers to fully qualified segment
identifiers. A common use of this would be from receivers to maintain
tables that map small segment identifiers to larger addresses. The
table is specific within a segment routing domain must be managed
accordingly. Using map values can be considerable savings in packet
overhead when segment routing is used, particularly when a segment
routing list would carry multiple IPv6 addresses.
3 Routing header security option
The routing header security options is a Destination Option that
provides security for a following routing header.
T. Herbert Expires September 12, 2019 [Page 5]
INTERNET DRAFT draft-herbert-simple-sr-00 March 11, 2019
The format of the option is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Sub-type specific data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields are:
o Type: Destination Option type for Routing Header security. This
is a non-modifiable option and must not be ignored. Accordingly,
the high order type bits are 010 to reflect that.
o Length: Variable length of option data.
o Sub-type: Security method used. This specification defines one
method of HMAC. See below.
o Reserved: MUST be set to zero when sending.
o Sub-type specific data: Data that is specific to the sub-type.
The sub-type specific data for HMAC is described below.
T. Herbert Expires September 12, 2019 [Page 6]
INTERNET DRAFT draft-herbert-simple-sr-00 March 11, 2019
3.1 HMAC Routing header security
HMAC Routing header security is a sub-type of routing header
security. The format of the sub-type specific data is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Key ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| //
| HMAC (32 octets) //
| //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
o HMAC Key ID: 4 octets.
o HMAC: 32 octets.
The operation of the HMAC with respect routing header is specified in
[SRV6EH].
3.2 Operation
The section describes the use and processing of the routing header
security Destination Option.
3.2.1 Sender operation
A sender may set a routing header security option in Destination
Options that precede a Routing Header.
A sender SHOULD follow the recommended ordering in RFC8200 that a
routing header immediately follows Destination Options that precede
the routing header. As described below, if destination options
immediately precede a routing header, a receive may apply the
security option to the routing header while processing the security
option as an optimization. To enable this, a sender MUST ensure that
the Routing header immediately follows the Destination Options, and
the routing header security option MUST be the last option in the
Destination Options.
3.2.2 Receiver operation
The security option MUST be processed by the last node in the routing
header list of nodes to visit, and MAY be processed by intermediate
T. Herbert Expires September 12, 2019 [Page 7]
INTERNET DRAFT draft-herbert-simple-sr-00 March 11, 2019
destinations. If a node does not process the option it MUST skip the
option and proceed to the next option.
As demonstrated in the HMAC description, the routing header security
option may be applied to fields in the routing header. Per [RFC8200],
extension headers cannot be processed out of order so care must be
taken to ensure processing order semantics are maintained. This
specification presents two alternative methods that should yield the
same effect.
When a node processes a routing header security option in Destination
Options, it can record the option data and make a note that the
security is to be applied to the routing header. Subsequently, when
the routing header is processed, the node can perform security
verification as the first step in processing the routing header.
An alternative is for a node to perform the security verification
when processing the security option in the Destination Options. A
receiver MUST only do this if the Routing header immediately follows
the Destination Options header and the routing header security option
is the last Destination option.
4 Process per segment Destination Option
A sender MAY indicate that certain destination options preceding a
Routing header are applicable to certain segments. A new option is
defined for this functionality. This option SHOULD only be used if
Destination Options immediately precedes a Routing header.
The format of the option is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Bit map ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Destination Option type for the process per segment
Destination Options. This is a non-modifiable option and must
not be ignored. Accordingly, the high order type bits are 010 to
reflect that.
o Length: Variable length of the bit map in octets.
o Bit map: A variable length bit map that describes which nodes
are to process the option.
A position in the bit map corresponds to a Segments Left value in the
T. Herbert Expires September 12, 2019 [Page 8]
INTERNET DRAFT draft-herbert-simple-sr-00 March 11, 2019
Routing header. For instance, if bit 3 in the bit map is set, then
the option is processed by the node when Segments Left is 3. A bit
map can indicate that multiple nodes are to process the options. Bits
beyond the length of the bit map are assumed be zero.
If the length of the bit map is zero (i.e. length of the option data
is zero) then any following options are MUST be processed by all
intermediate nodes.
4.1 Sender operation
A sender MAY set the process per segment Destination Option. The
Destination Options SHOULD immediately precede a Routing Header. The
sender MAY indicate in the bit map that multiple intermediate
destinations must process the options that following the process per
segment option. Any Destination options MAY follow the process per
segment option. A sender MAY direct options at different sets of
intermediate destination by setting the per segment Destination
option for each set. Options that precede a per segment Destination
option are expected to be processed normally by each destination.
4.2 Receiver operation
When a node receives a process per segment Destination option it
performs the following processing:
1) Check if the Next Header in the Destination Options header
indicates a routing header (i.e. Next Header is equal to 43).
If the next header is not a Routing header then processing the
Destination Options is complete. Any following options are
ignored.
2) Extract the Segments Left value from the Routing header
immediately following the Destination Options header.
3) Determine the value in the bit map of the process per Segment
option corresponding to the Segments Left value.
- If the bit map value is set (bit is one) then process any
following options to the end of the options list or another
process per Segment option encountered.
- If the bit map value is unset (bit is zero) then skip any
following options to the end of the options list or another
process per Segment option encountered.
4) If another process per Segment option is encountered process it
starting from step #3 above
T. Herbert Expires September 12, 2019 [Page 9]
INTERNET DRAFT draft-herbert-simple-sr-00 March 11, 2019
5 Security Considerations
This document defines new Destination option that is use to provide
security for a routing header.
6 IANA Considerations
IANA is requested to assign two Destination options types.
IANA is requested to create a sub-type registry for the routing
header security Destination Option.
7 References
7.1 Normative References
7.2 Informative References
[SRV6EH] Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-16.
[SRCOMP] Bonica, R., Xu, X., Chen, G., Zhu, Y., and Yang, G., "The
IPv6 Compressed Routing Header (CRH)", draft-bonica-6man-
comp-rtg-hdr-01.
[SRENDOPT] Bonica, R., Xu, X., Chen, G., Zhu, Y., and Yang, G., "The
IPv6 Segment Endpoint Option", draft-bonica-6man-seg-end-
opt-02
Author's Address
Tom Herbert
Quantonium
Santa Clara, CA
USA
Email: tom@quantonium.net
T. Herbert Expires September 12, 2019 [Page 10]
