draft-ietf-6man-segment-routing-header-04.txt   draft-ietf-6man-segment-routing-header-05.txt 
Network Working Group S. Previdi, Ed. Network Working Group S. Previdi, Ed.
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: July 22, 2017 B. Field Expires: August 5, 2017 B. Field
Comcast Comcast
I. Leung I. Leung
Rogers Communications Rogers Communications
J. Linkova J. Linkova
Google Google
E. Aries E. Aries
Facebook Facebook
T. Kosugi T. Kosugi
NTT NTT
E. Vyncke E. Vyncke
Cisco Systems, Inc. Cisco Systems, Inc.
D. Lebrun D. Lebrun
Universite Catholique de Louvain Universite Catholique de Louvain
January 18, 2017 February 1, 2017
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-04 draft-ietf-6man-segment-routing-header-05
Abstract Abstract
Segment Routing (SR) allows a node to steer a packet through a Segment Routing (SR) allows a node to steer a packet through a
controlled set of instructions, called segments, by prepending an SR controlled set of instructions, called segments, by prepending an SR
header to the packet. A segment can represent any instruction, header to the packet. A segment can represent any instruction,
topological or service-based. SR allows to enforce a flow through topological or service-based. SR allows to enforce a flow through
any path (topological, or application/service based) while any path (topological, or application/service based) while
maintaining per-flow state only at the ingress node to the SR domain. maintaining per-flow state only at the ingress node to the SR domain.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 July 22, 2017. This Internet-Draft will expire on August 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 8, line 10 skipping to change at page 8, line 10
defined: the Segment Routing Header (SRH) which has a new Routing defined: the Segment Routing Header (SRH) which has a new Routing
Type, (suggested value 4) to be assigned by IANA. Type, (suggested value 4) to be assigned by IANA.
The Segment Routing Header (SRH) is defined as follows: The Segment Routing Header (SRH) is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left | | Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Segment | Flags | RESERVED | | First Segment | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Segment List[0] (128 bits IPv6 address) | | Segment List[0] (128 bits IPv6 address) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
... ...
| | | |
skipping to change at page 8, line 51 skipping to change at page 8, line 51
o Routing Type: TBD, to be assigned by IANA (suggested value: 4). o Routing Type: TBD, to be assigned by IANA (suggested value: 4).
o Segments Left. Defined in [RFC2460], it contains the index, in o Segments Left. Defined in [RFC2460], it contains the index, in
the Segment List, of the next segment to inspect. Segments Left the Segment List, of the next segment to inspect. Segments Left
is decremented at each segment. is decremented at each segment.
o First Segment: contains the index, in the Segment List, of the o First Segment: contains the index, in the Segment List, of the
first segment of the path which is in fact the last element of the first segment of the path which is in fact the last element of the
Segment List. Segment List.
o Flags: 16 bits of flags. Following flags are defined: o Flags: 8 bits of flags. Following flags are defined:
1 0 1 2 3 4 5 6 7
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|P|O|A|H| U |
|U|P|O|A|H| Unused | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"U" and Unused: Reserved and for future use. SHOULD be unset U: Unused and for future use. SHOULD be unset on transmission
on transmission and MUST be ignored on receipt. and MUST be ignored on receipt.
P-flag: Protected flag. Set when the packet has been rerouted P-flag: Protected flag. Set when the packet has been rerouted
through FRR mechanism by an SR endpoint node. through FRR mechanism by an SR endpoint node.
O-flag: OAM flag. When set, it indicates that this packet is O-flag: OAM flag. When set, it indicates that this packet is
an operations and management (OAM) packet. an operations and management (OAM) packet.
A-flag: Alert flag. If present, it means important Type Length A-flag: Alert flag. If present, it means important Type Length
Value (TLV) objects are present. See Section 3.1 for details Value (TLV) objects are present. See Section 3.1 for details
on TLVs objects. on TLVs objects.
skipping to change at page 16, line 38 skipping to change at page 16, line 38
4. Forward the packet out 4. Forward the packet out
5. Security Considerations 5. Security Considerations
This section analyzes the security threat model, the security issues This section analyzes the security threat model, the security issues
and proposed solutions related to the new Segment Routing Header. and proposed solutions related to the new Segment Routing Header.
The Segment Routing Header (SRH) is simply another type of the The Segment Routing Header (SRH) is simply another type of the
routing header as described in RFC 2460 [RFC2460] and is: routing header as described in RFC 2460 [RFC2460] and is:
o inserted by an SR edge router when entering the segment routing o Added by an SR edge router when entering the segment routing
domain or by the originating host itself. The source host can domain or by the originating host itself. The source host can
even be outside the SR domain; even be outside the SR domain;
o inspected and acted upon when reaching the destination address of o inspected and acted upon when reaching the destination address of
the IP header per RFC 2460 [RFC2460]. the IP header per RFC 2460 [RFC2460].
Per RFC2460 [RFC2460], routers on the path that simply forward an Per RFC2460 [RFC2460], routers on the path that simply forward an
IPv6 packet (i.e. the IPv6 destination address is none of theirs) IPv6 packet (i.e. the IPv6 destination address is none of theirs)
will never inspect and process the content of the SRH. Routers whose will never inspect and process the content of the SRH. Routers whose
one interface IPv6 address equals the destination address field of one interface IPv6 address equals the destination address field of
skipping to change at page 21, line 13 skipping to change at page 21, line 13
quick interoperations testing, the 160-bit hash value must then be quick interoperations testing, the 160-bit hash value must then be
right-hand padded with 96 bits set to 0. The authors understand that right-hand padded with 96 bits set to 0. The authors understand that
this is not secure but is ok for limited tests. this is not secure but is ok for limited tests.
5.2.2. Performance impact of HMAC 5.2.2. Performance impact of HMAC
While adding an HMAC to each and every SR packet increases the While adding an HMAC to each and every SR packet increases the
security, it has a performance impact. Nevertheless, it must be security, it has a performance impact. Nevertheless, it must be
noted that: noted that:
o the HMAC field is used only when SRH is inserted by a device (such o the HMAC field is used only when SRH is added by a device (such as
as a home set-up box) which is outside of the segment routing a home set-up box) which is outside of the segment routing domain.
domain. If the SRH is added by a router in the trusted segment If the SRH is added by a router in the trusted segment routing
routing domain, then, there is no need for an HMAC field, hence no domain, then, there is no need for an HMAC field, hence no
performance impact. performance impact.
o when present, the HMAC field MUST only be checked and validated by o when present, the HMAC field MUST only be checked and validated by
the first router of the segment routing domain, this router is the first router of the segment routing domain, this router is
named 'validating SR router'. Downstream routers may not inspect named 'validating SR router'. Downstream routers may not inspect
the HMAC field. the HMAC field.
o this validating router can also have a cache of <IPv6 header + o this validating router can also have a cache of <IPv6 header +
SRH, HMAC field value> to improve the performance. It is not the SRH, HMAC field value> to improve the performance. It is not the
same use case as in IPsec where HMAC value was unique per packet, same use case as in IPsec where HMAC value was unique per packet,
skipping to change at page 22, line 18 skipping to change at page 22, line 18
o dynamically using a trusted key distribution such as [RFC6407] o dynamically using a trusted key distribution such as [RFC6407]
The intent of this document is NOT to define yet-another-key- The intent of this document is NOT to define yet-another-key-
distribution-protocol. distribution-protocol.
5.3. Deployment Models 5.3. Deployment Models
5.3.1. Nodes within the SR domain 5.3.1. Nodes within the SR domain
An SR domain is defined as a set of interconnected routers where all An SR domain is defined as a set of interconnected routers where all
routers at the perimeter are configured to insert and act on SRH. routers at the perimeter are configured to add and act on SRH. Some
Some routers inside the SR domain can also act on SRH or simply routers inside the SR domain can also act on SRH or simply forward
forward IPv6 packets. IPv6 packets.
The routers inside an SR domain can be trusted to generate SRH and to The routers inside an SR domain can be trusted to generate SRH and to
process SRH received on interfaces that are part of the SR domain. process SRH received on interfaces that are part of the SR domain.
These nodes MUST drop all SRH packets received on an interface that These nodes MUST drop all SRH packets received on an interface that
is not part of the SR domain and containing an SRH whose HMAC field is not part of the SR domain and containing an SRH whose HMAC field
cannot be validated by local policies. This includes obviously cannot be validated by local policies. This includes obviously
packet with an SRH generated by a non-cooperative SR domain. packet with an SRH generated by a non-cooperative SR domain.
If the validation fails, then these packets MUST be dropped, ICMP If the validation fails, then these packets MUST be dropped, ICMP
error messages (parameter problem) SHOULD be generated (but rate error messages (parameter problem) SHOULD be generated (but rate
skipping to change at page 24, line 46 skipping to change at page 24, line 46
8. Contributors 8. Contributors
Dave Barach, John Leddy, John Brzozowski, Pierre Francois, Nagendra Dave Barach, John Leddy, John Brzozowski, Pierre Francois, Nagendra
Kumar, Mark Townsley, Christian Martin, Roberta Maglione, James Kumar, Mark Townsley, Christian Martin, Roberta Maglione, James
Connolly, Aloys Augustin contributed to the content of this document. Connolly, Aloys Augustin contributed to the content of this document.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Ole Troan, Bob Hinden, Fred Baker, The authors would like to thank Ole Troan, Bob Hinden, Fred Baker,
Brian Carpenter and Alexandru Petrescu for their comments to this Brian Carpenter, Alexandru Petrescu and Punit Kumar Jaiswal for their
document. comments to this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[FIPS180-4] [FIPS180-4]
National Institute of Standards and Technology, "FIPS National Institute of Standards and Technology, "FIPS
180-4 Secure Hash Standard (SHS)", March 2012, 180-4 Secure Hash Standard (SHS)", March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
skipping to change at page 26, line 8 skipping to change at page 26, line 8
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3- Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-07 (work in progress), October segment-routing-extensions-07 (work in progress), October
2016. 2016.
[I-D.ietf-spring-ipv6-use-cases] [I-D.ietf-spring-ipv6-use-cases]
Brzozowski, J., Leddy, J., Townsley, W., Filsfils, C., and Brzozowski, J., Leddy, J., Townsley, W., Filsfils, C., and
R. Maglione, "IPv6 SPRING Use Cases", draft-ietf-spring- R. Maglione, "IPv6 SPRING Use Cases", draft-ietf-spring-
ipv6-use-cases-07 (work in progress), July 2016. ipv6-use-cases-08 (work in progress), January 2017.
[I-D.ietf-spring-resiliency-use-cases] [I-D.ietf-spring-resiliency-use-cases]
Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, Filsfils, C., Previdi, S., Decraene, B., and R. Shakir,
"Resiliency use cases in SPRING networks", draft-ietf- "Resiliency use cases in SPRING networks", draft-ietf-
spring-resiliency-use-cases-08 (work in progress), October spring-resiliency-use-cases-08 (work in progress), October
2016. 2016.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- and R. Shakir, "Segment Routing Architecture", draft-ietf-
 End of changes. 13 change blocks. 
24 lines changed or deleted 23 lines changed or added

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