Flowspec Indirection-id Redirect for SRv6
draft-ietf0-idr-srv6-flowspec-path-redirect-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Gunter Van de Velde , Keyur Patel , Zhenbin Li , Huaimo Chen | ||
| Last updated | 2018-10-22 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| 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-ietf0-idr-srv6-flowspec-path-redirect-00
IDR Working Group G. Van de Velde
Internet-Draft Nokia
Intended status: Standards Track K. Patel
Expires: April 25, 2019 Arrcus
Z. Li
H. Chen
Huawei Technologies
October 22, 2018
Flowspec Indirection-id Redirect for SRv6
draft-ietf0-idr-srv6-flowspec-path-redirect-00
Abstract
This document defines extensions to "FlowSpec Redirect to
indirection-id Extended Community" for SRv6. This extended community
can trigger advanced redirection capabilities to flowspec clients for
SRv6. When activated, this flowspec extended community is used by a
flowspec client to retrieve the corresponding next-hop and encoding
information within a localised indirection-id mapping table.
The functionality detailed in this document allows a network
controller to decouple the BGP flowspec redirection instruction from
the operation of the available paths.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
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 April 25, 2019.
Van de Velde, et al. Expires April 25, 2019 [Page 1]
Internet-Draft Indirection-id Redirect for SRv6 October 2018
Copyright Notice
Copyright (c) 2018 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Redirect to indirection-id Community . . . . . . . . . . . . 2
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
"FlowSpec Redirect to indirection-id Extended Community" for IPv4 is
defined in ietf-idr-flowspec-path-redirect [1]. This draft specifies
extensions to this community for SRv6.
2. Redirect to indirection-id Community
This document defines a new sub-type value for SRv6 in '
At about the time that the TA expects clients to start setting key
'B' as the current key, the TA must release a new TAL file for key
'B'. It SHOULD use a different set of URIs in the TAL compared to
the TAK file, so that the TA can learn the proportion of RPs that can
successfully validate and use the updated TAK objects.
To support RPs that do not take account of TAK objects, the TA should
continue operating key 'A' for a period of time after the expected
migration of clients to 'B'. The length of that period of time is a
local policy matter for that TA: it might operate the key until no
clients are attempting to validate using it, for example.
7.4. Phase 4: Remove Key 'A'
The TA SHOULD now remove all content from the repository used by key
'A', and destroy the private key for key 'A'. RPs attempting to rely
on a TAL for key 'A' from this point will not be able to perform RPKI
validation for the TA, and will have to update their local state
manually, by way of a new TAL file.
8. Using TAK objects to distribute TAL data
Relying Parties must be configured with RPKI Trust Anchor data in
order to function correctly. This Trust Anchor data is typically
distributed in the Trust Anchor Locator (TAL) format defined in RFC
8630. A TAK object can also serve as a format for distribution of
this data, though, because the TAKey data stored in the TAK object
contains the same data that would appear in a TAL for the associated
Trust Anchor.
Relying Parties may support conversion of TAK objects into TAL files.
Relying Parties that support conversion MUST validate the TAK object
using the process from section 3.3. One exception to the standard
validation process in this context is that a Relying Party MAY treat
a TAK object as valid, even though it is associated with a Trust
Anchor that the Relying Party is not currently configured to trust.
If the Relying Party is relying on this exception when converting a
given TAK object, the Relying Party MUST communicate that fact to the
user.
When converting a TAK object, a Relying Party MUST default to
producing a TAL file based on the 'current' TAKey in the TAK object,
though it MAY optionally support producing TAL files based on the
'predecessor' and 'successor' TAKeys.
Martinez, et al. Expires 12 October 2024 [Page 12]
Internet-Draft RPKI signed object for TAL April 2024
When converting a TAK object, a Relying Party MUST include in the TAL
file any comments from the corresponding TAKey.
If TAK object validation fails, then the Relying Party MUST NOT
produce a TAL file based on the TAK object.
Users should be aware that TAK objects distributed out-of-band have
similar security properties to TAL files (i.e. there is no
authentication). In particular, TAK objects that are not signed by
TAs with which the Relying Party is currently configured should only
be used if the source that distributes them is one the user trusts to
distribute TAL files.
If a Relying Party is not transitioning to new Trust Anchor data
using the automatic process described in section 5 or the partially-
manual process described in section 5.1, then the user will have to
rely on an out-of-band mechanism for validating and updating the
Trust Anchor data for the Relying Party. Users in this situation
should take similar care when updating a trust anchor using a TAK
object file as when using a TAL file to update TA data.
9. Deployment Considerations
9.1. Relying Party Support
Publishing TAK objects while RPs do not support this standard will
result in those RPs rejecting these objects. It is not expected that
this will result in the invalidation of any other object under a
Trust Anchor.
Some RPs may purposefully not support this mechanism: for example,
they may be implemented or configured such that they are unable to
update local current key data. TAs should take this into
consideration when planning key rollover. However, these RPs would
ideally still notify their operators of planned key rollovers, so
that the operator could update the relevant configuration manually.
9.2. Alternate Transition Models
Alternate models of TAL update exist and are complementary to this
mechanism. For example, TAs can liaise directly with RP software
developers to include updated and reissued TAL files in new code
releases, and use existing code update mechanisms in the RP community
to distribute the changes.
Martinez, et al. Expires 12 October 2024 [Page 13]
Internet-Draft RPKI signed object for TAL April 2024
Additionally, these non-TA channels for distributing TAL data may
themselves rely on monitoring for TAK objects and then updating the
TAL data in their distributions or packages accordingly. In this
way, TAK objects may be useful even for RPs that don't implement in-
band support for the protocol.
Non-TA channels for distributing TAL data should ensure, so far as is
possible, that their update mechanisms take account of any changes
that a user has made to their local TA key configuration. For
example, if a new key is published for a TA, but the non-TA channel's
mechanism is able to detect that a user had removed the TA's previous
key from their local TA key configuration such that the user no
longer relies on it, then the mechanism should not by default add the
new key to the user's TA key configuration.
10. Operational Considerations
10.1. Acceptance Timers
Acceptance timers are used in TAK objects in order to permit RPs to
test that the new key is working correctly. This in turn means that
the TA will be able to gain confidence in the correct functioning of
the new key before RPs are relying on that in their production RPKI
operations. If a successor key is not working correctly, a TA may
remove that key from the current TAK object.
A TA that removes a successor key from a TAK object SHOULD NOT add
the same successor key back into the TAK object for that TA. This is
because there may be an RP that has fetched the TAK object while the
successor key was listed in it, and has started an acceptance timer
accordingly, but has not fetched the TAK object during the period
when the successor key was not listed in it. If the unchanged
successor key is added back into the TA, such an RP will transition
to using the new TA key more quickly than other RPs, which may, in
turn, make debugging and similar more complicated. A simple way of
addressing this problem in a situation where the TA doesn't want to
reissue the SubjectPublicKeyInfo content for the successor key that
was withdrawn is to update the URL set for the successor key, since
RPs must take that URL set into account for the purposes of
initiating and cancelling acceptance timers.
11. Security Considerations
Martinez, et al. Expires 12 October 2024 [Page 14]
Internet-Draft RPKI signed object for TAL April 2024
11.1. Previous Keys
A TA needs to consider the length of time for which it will maintain
previously-current keys and their associated repositories. An RP
that is seeded with old TAL data will run for 30 days using the
previous key before migrating to the next key, due to the acceptance
timer requirements, and this 30-day delay applies to each new key
that has been issued since the old TAL data was initially published.
It may be better in these instances to have the old publication URLs
simply fail to resolve, so that the RP reports an error to its
operator and the operator seeds it with up-to-date TAL data
immediately.
Once a TA has decided not to maintain a previously-current key and
its associated repository, the TA SHOULD destroy that key. The TA
SHOULD also reuse the TA CA certificate URLs from the previous TAL
data for the next TAL that it generates. These measures will help to
mitigate the risk of an adversary gaining access to the key and its
associated publication points in order to send invalid/incorrect data
to RPs seeded with the TAL data for that key.
11.2. TA Compromise
TAK objects do not offer protection against compromise of the current
TA key or the successor TA key. TA key compromise in general is out
of scope for this document.
12. IANA Considerations
12.1. Content Type
IANA is asked to register an object identifier for one content type
in the "SMI Security for S/MIME CMS Content Type
(1.2.840.113549.1.9.16.1)" registry as follows:
Decimal | Description | References
--------+--------------------------------+---------------
50 | id-ct-signedTAL | [section 3.1]
* Description: id-ct-signedTAL
* OID: 1.2.840.113549.1.9.16.1.50
* Specification: [section 3.1]
Martinez, et al. Expires 12 October 2024 [Page 15]
Internet-Draft RPKI signed object for TAL April 2024
12.2. Signed Object
IANA is asked to add the following to the "RPKI Signed Objects"
registry:
Name | OID | Reference
-----------------+----------------------------+---------------
Trust Anchor Key | 1.2.840.113549.1.9.16.1.50 | [section 3.1]
IANA is also asked to add the following note to the "RPKI Signed
Objects" registry:
| Objects of the types listed in this registry, as well as RPKI
| resource certificates and CRLs, are expected to be validated using
| the RPKI.
12.3. File Extension
IANA is asked to add an item for the Signed TAL file extension to the
"RPKI Repository Name Scheme" created by [RFC6481] as follows:
Filename Extension | RPKI Object | Reference
--------------------+--------------------------+----------------
.tak | Trust Anchor Key | [this document]
12.4. Module Identifier
IANA is asked to register an object identifier for one module
identifier in the "SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0)" registry as follows:
Decimal | Description | References
--------+--------------------------------+---------------
74 | RPKISignedTrustAnchorList-2021 | [this document]
* Description: RPKISignedTrustAnchorList-2021
* OID: 1.2.840.113549.1.9.16.0.74
* Specification: [this document]
12.5. Registration of Media Type application/rpki-signed-tal
IANA is asked to register the media type "application/rpki-signed-
tal" in the "Media Types" registry as follows:
Type name: application
Martinez, et al. Expires 12 October 2024 [Page 16]
Internet-Draft RPKI signed object for TAL April 2024
Subtype name: rpki-signed-tal
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security considerations: Carries an RPKI Signed TAL. This media
type contains no active content. See the Security Considerations
section of RFC XXXX for further information.
Interoperability considerations: N/A
Published specification: RFC XXXX
Applications that use this media type: RPKI operators
Fragment identifier considerations: N/A
Additional information: Content: This media type is for a signed
object, as defined in RFC 6488, which contains trust anchor key
material as defined in RFC XXXX.
Magic number(s): N/A
File extension(s): .tak
Macintosh file type code(s): N/A
Person & email address to contact for further information:
iesg@ietf.org
Intended usage: COMMON
Restrictions on usage: N/A
Author: sidrops WG
Change controller: IESG
13. Implementation Status
NOTE: Please remove this section and the reference to RFC 7942 prior
to publication as an RFC.
Martinez, et al. Expires 12 October 2024 [Page 17]
Internet-Draft RPKI signed object for TAL April 2024
"FlowSpec
Redirect to indirection-id Extended Community". The format of this
extended community with the new sub-type value is show below:
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 |Sub-Type (TBD) | Flags(1 octet)| ID-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generalized indirection_id (16 octets) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Van de Velde, et al. Expires April 25, 2019 [Page 2]
Internet-Draft Indirection-id Redirect for SRv6 October 2018
Where
Type: 1 octet, defined in ietf-idr-flowspec-path-redirect [1].
Sub-Type: 1 octet, its value (TBD) will be assigned by IANA.
Flags: Same as that defined in ietf-idr-flowspec-path-redirect [1].
ID-Type: 1 octet value. This draft defines following Context Types:
0 - Localised ID (The flowspec client uses the received
indirection-id to lookup forwarding information within the
localised indirection-id table. The allocation and programming of
the localised indirection-id table is outside scope of the
document)
1 - Node ID with SID/index in MPLS-based Segment Routing (This
means the indirection-id is mapped to an MPLS label using the
index as a global offset in the SID/label space)
2 - Node ID with SID/label in MPLS-based Segment Routing (This
means the indirection-id is mapped to an MPLS label using the
indirection-id as global label)
3 - Binding Segment ID with SID/index in MPLS-based Segment
Routing (This means the indirection-id is mapped to an MPLS
binding label using the indirection-id as index for global offset
in the SID/label space).
4 - Binding Segment ID with SID/label in MPLS-based Segment
Routing (This means indirection-id is mapped to an MPLS binding
label using the indirection-id as global label).
5 - Tunnel ID (Tunnel ID is within a single administrative domain
a globally unique tunnel identifier. The allocation and
programming of the Tunnel ID within the localised indirection-id
table is outside scope of the document)
6 - Node ID with SID/index in SRv6 (This means the indirection-id
is mapped to an SRv6 SID using the indirection-id as global SRv6
SID or index)
7 - Binding Segment ID with SID/index in SRv6 (This means the
indirection-id is mapped to an SRv6 binding SID using the
indirection-id as index for global offset in the SID space).
Van de Velde, et al. Expires April 25, 2019 [Page 3]
Internet-Draft Indirection-id Redirect for SRv6 October 2018
8 - Binding Segment ID with SID/index in SRv6 (This means
indirection-id is mapped to an SRv6 binding SID using the
indirection-id as global SRv6 SID).
Generalized indirection_id: 128-bit identifier used as indirection_id
3. Security Considerations
A system using "Redirect to indirection-id" extended community can
cause during the redirect mitigation of a DDoS attack overflow of
traffic received by the mitigation infrastructure.
4. Acknowledgements
This document received valuable comments and input from IDR working
group including Adam Simpson, Mustapha Aissaoui, Jan Mertens, Robert
Raszuk, Jeff Haas, Susan Hares and Lucy Yong.
5. Contributor Addresses
Below is a list of other contributing authors in alphabetical order:
Arjun Sreekantiah
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: asreekan@cisco.com
Nan Wu
Huawei Technologies
Huawei Bld., No. 156 Beiquing Rd
Beijing 100095
China
Email: eric.wu@huawei.com
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No. 156 Beiquing Rd
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Van de Velde, et al. Expires April 25, 2019 [Page 4]
Internet-Draft Indirection-id Redirect for SRv6 October 2018
Wim Henderickx
Nokia
Antwerp
BE
Email: wim.henderickx@nokia.com
6. IANA Considerations
This document requests a new sub-type value under "FlowSpec Redirect
to indirection-id Extended Community Sub-Type" registery.
Value Code Reference
0x01 Flowspec Redirect to 128-bit Path-id for SRv6 [RFC-To-Be]
7. References
7.1. Normative References
[1] Velde, G., Patel, K., and Z. Li, "Flowspec Indirection-id
Redirect", draft-ietf-idr-flowspec-path-redirect-06 (work
in progress), June 2018.
[2] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://xml.resource.org/public/rfc/html/rfc2119.html>.
[3] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<https://www.rfc-editor.org/info/rfc5575>.
7.2. Informative References
[4] Uttaro, J., Filsfils, C., Alcaide, J., and P. Mohapatra,
"Revised Validation Procedure for BGP Flow
Specifications", January 2014.
[5] Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D.
Afanasiev, "Segment Routing Centralized Egress Peer
Engineering", October 2015.
[6] Sreekantiah, A., Filsfils, C., Previdi, S., Sivabalan, S.,
Mattes, P., and S. Lin, "Segment Routing Traffic
Engineering Policy using BGP", October 2015.
Van de Velde, et al. Expires April 25, 2019 [Page 5]
Internet-Draft Indirection-id Redirect for SRv6 October 2018
[7] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
Shakir, R., Bashandy, A., Horneffer, M., Henderickx, W.,
Tantsura, J., Crabbe, E., Milojevic, I., and S. Ytti,
"Segment Routing Architecture", December 2015.
[8] Sivabalan, S., Medved, M., Filsfils, C., Litkowski, S.,
Raszuk, R., Bashandy, A., Lopez, V., Tantsura, J.,
Henderickx, W., Hardwick, J., Milojevic, I., and S. Ytti,
"PCEP Extensions for Segment Routing", December 2015.
Authors' Addresses
Gunter Van de Velde
Nokia
Antwerp
BE
Email: gunter.van_de_velde@nokia.com
Keyur Patel
Arrcus
USA
Email: keyur@arrcus.com
Zhenbin Li
Huawei Technologies
Huawei Bld., No. 156 Beiquing Rd
Beijing 100095
China
Email: lizhenbin@huawei.com
Huaimo Chen
Huawei Technologies
Boston, MA
USA
Email: Huaimo.chen@huawei.com
Van de Velde, et al. Expires April 25, 2019 [Page 6]