< draft-xie-bier-ipv6-encapsulation-03.txt   draft-xie-bier-ipv6-encapsulation-04.txt >
Network Working Group J. Xie Network Working Group J. Xie
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track L. Geng Intended status: Standards Track L. Geng
Expires: January 21, 2020 China Mobile Expires: June 13, 2020 China Mobile
M. McBride M. McBride
Futurewei Futurewei
R. Asati R. Asati
Cisco Cisco
S. Dhanaraj S. Dhanaraj
Huawei Huawei
July 20, 2019 December 11, 2019
Encapsulation for BIER in Non-MPLS IPv6 Networks Encapsulation for BIER in Non-MPLS IPv6 Networks
draft-xie-bier-ipv6-encapsulation-03 draft-xie-bier-ipv6-encapsulation-04
Abstract Abstract
This document proposes a BIER IPv6 (BIERv6) encapsulation for Non- This document proposes a BIER IPv6 (BIERv6) encapsulation for Non-
MPLS IPv6 Networks using the IPv6 Destination Option extension MPLS IPv6 Networks using the IPv6 Destination Option extension
header. header.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 January 21, 2020. This Internet-Draft will expire on June 13, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BIER IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 3 3. BIER IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 3
3.1. BIER Option in IPv6 Destination Options Header . . . . . 3 3.1. BIER Option in IPv6 Destination Options Header . . . . . 3
3.2. Multicast and Unicast Destination Address . . . . . . . . 6 3.2. Multicast and Unicast Destination Address . . . . . . . . 6
3.3. BIERv6 Packet Format . . . . . . . . . . . . . . . . . . 8 3.3. BIERv6 Packet Format . . . . . . . . . . . . . . . . . . 8
4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9 4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 12
6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 11 5.2. Inter Domain Deployment . . . . . . . . . . . . . . . . . 13
6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 11 5.3. ICMP Error Processing . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 5.4. Security caused by BIER option . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Applicability of IPsec . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 12 6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Bit Index Explicit Replication (BIER) [RFC8279] is an architecture Bit Index Explicit Replication (BIER) [RFC8279] is an architecture
that provides optimal multicast forwarding without requiring that provides optimal multicast forwarding without requiring
intermediate routers to maintain any per-flow state by using a intermediate routers to maintain any per-flow state by using a
multicast-specific BIER header. multicast-specific BIER header.
[RFC8296] defines a common BIER Header format for MPLS and Non-MPLS [RFC8296] defines a common BIER Header format for MPLS and Non-MPLS
networks. It has defined two types of encapsulation methods using networks. It has defined two types of encapsulation methods using
skipping to change at page 10, line 47 skipping to change at page 11, line 11
the multicast flow overlay. The egress VRF of a packet may be the multicast flow overlay. The egress VRF of a packet may be
determined by a further lookup on the IPv6 source address instead of determined by a further lookup on the IPv6 source address instead of
the upstream-assigned MPLS Label as described in [RFC8556]. the upstream-assigned MPLS Label as described in [RFC8556].
The Fragment Header, AH Header or ESP Header, if exists after the The Fragment Header, AH Header or ESP Header, if exists after the
BIER options header, can be processed on BFER only as part of the BIER options header, can be processed on BFER only as part of the
multicast flow overlay process. multicast flow overlay process.
5. Security Considerations 5. Security Considerations
A BIERv6 packet with a special IPv6 Destination Address, the BFR BIER IPv6 encapsulation provides a new encapsulation based on IPv6
prefix functioning as End.BIER, would be processed by BIER forwarding and BIER to transport multicast data packet in a BIER domain. The
procedure only when the 'BIER Specific Handling' flag has been BIER domain can be a single IGP area, an anonymous system (AS) with
obtained ahead in the FIB lookup of the IPv6 header. Otherwise the multiple IGP areas, or multiple anonymous systems (ASes) operated by
packet with an IPv6 BIER Option will not be processed by the a network operator. This section reviews security considerations
procedure but be processed as normal IPv6 packet. A possible way of related to the BIER IPv6 encapsulation, based on security
handling IPv6 packets with extension may be send to CPU for slow path considerations of [RFC8279], [RFC8296], and other documents related
processing. to IPv6 extension.
BIER-encapsulated packets should generally not be accepted from
untrusted interfaces or tunnels. For example, an operator may wish
to have a policy of accepting BIER-encapsulated packets only from
interfaces to trusted routers, and not from customer-facing
interfaces. See section 5.1 for normal Intra domain deployment.
There may be applications that require a BFR to accept a BIER-
encapsulated packet from an interface to a system that is not
controlled by the network operator. See section 5.2 for inter domain
deployment.
BIER IPv6 encapsulation may cause ICMP packet sent to BFIR and cause
security problems. See section 5.3 for ICMP related problems.
This document introduces a new option used in IPv6 Destination
Options Header, together with the special-use IPv6 address called
End.BIER in IPv6 destination address for BIER IPv6 forwarding.
However the option newly introduced may be wrongly used with normal
IPv6 destination address. See section 5.4 for problems introduced by
the new IPv6 option with normal IPv6 destination address.
If a BIER packet is altered, either the BIER header, or the multicast
data packet, by an intermediate router, packets may be lost, stolen,
or otherwise misdelivered. BIER IPv6 encapsulation provides the
ability of IPsec to ensure the confidentiality or integrity. See
section 5.5 for this security problem.
A BIER router accepts and uses the End.BIER IPv6 address to construct
BIFT only when the IPv6 address is configured explicitly, or received
from a router via control-plane protocols. The received information
is validated using existing authentication and security mechanisms of
the control-plane protocols. BIER IPv6 encapsulation does not define
any additional security mechanism in existing control-plane
protocols, and it inherits any security considerations that apply to
the control-plane protocols.
5.1. Intra Domain Deployment
Generally nodes outside the BIER Domain are not trusted: they cannot
directly use the End.BIER of the domain. This is enforced by two
levels of access control lists:
1. Any packet entering the BIER Domain and destined to an End.BIER
IPv6 Address within the BIER Domain is dropped. This may be realized
with the following logic. Other methods with equivalent outcome are
considered compliant:
* allocate all the End.BIER IPv6 Address from a block S/s
* configure each external interface of each edge node of the domain
with an inbound infrastructure access list (IACL) which drops any
incoming packet with a destination address in S/s
* Failure to implement this method of ingress filtering exposes the
BIER Domain to BIER attacks as described and referenced in [RFC8296].
2. The distributed protection in #1 is complemented with per node
protection, dropping packets to End.BIER IPv6 Address from source
addresses outside the BIER Domain. This may be realized with the
following logic. Other methods with equivalent outcome are
considered compliant:
* assign all interface addresses from prefix A/a
* assign all the IPv6 addresses used as source address of BIER IPv6
packets from a block B/b
* at node k, all End.BIER IPv6 addresses local to k are assigned from
prefix Sk/sk
* configure each internal interface of each BIER node k in the BIER
Domain with an inbound IACL which drops any incoming packet with a
destination address in Sk/sk if the source address is not in A/a or
B/b.
For simplicity of deployment, a configuration of IACL effective for
all interfaces can be provided by a router. Such IACL can be
referred to as global IACL(GIACL) .Each BIER node k then simply
configs a GIACL which drops any incoming packet with a destination
address in Sk/sk if the source address is not in A/a or B/b for the
inter-domain deployment mode.
5.2. Inter Domain Deployment
There may be applications that require a BFR to accept a BIER-
encapsulated packet from an interface to a system that is not
controlled by the network operator. For instance, there may be an
application in which a virtual machine in a data center submits BIER-
encapsulated packets to a router. In such a case, it is desirable to
verify that the packet is from a legitimate source and that its
BitString denotes only systems to which that source is allowed to
send. Using BIER IPv6 encapsulation, IACL can be configured on each
internal interface of each BIER node k to allow packet with a
destination address in Sk/sk and the source address is in an allowed
list of IPv6 address. However, the BIER IPv6 encapsulation itself
does not provide a way to verify that the source is legitimate or the
source is allowed to set any particular set of bits in the BitString.
The IACL allowing specific IPv6 address outside the domain of a
network operator can be more strict by the following method:
* configure one sub-domain using only one bit string length, and a
seperate End.BIER for this sub-domain as a service opened to agreed
source(s) outside the domain of the operator's network.
* configure on BIER node to check if the End.BIER address of a packet
is the correct one bound to the sub-domain of a packet.
* configure IACL on each interface of each BIER node k (or simply
configure GIACL on each BIER node k) to allow packet with an End.BIER
as destination address and the allowed source(s) as source address.
This provides a way to ensure that the inter-domain source is allowed
to access only the BIER IPv6 transport service bound to a sub-domain
with a specific bit string length.
5.3. ICMP Error Processing
ICMP error packets generated within the BIER Domain are sent to
source nodes within the BIER Domain.
A large number of ICMP may be elicited and sent to a BFIR router, in
case when a BIER IPv6 packet is filled with wrong TTL, either error
or malfeasance. A rate-limiting of ICMP packet should be implemented
on each BFR.
The ingress node can take note of the fact that it is getting, in
response to BIER IPv6 packet, one or more ICMP error packets. By
default, the reception of such a packets MUST be countered and
logged. However, it is possible for such log entries to be "false
positives" that generate a lot of "noise" in the log; therefore,
implementations SHOULD have a knob to disable this logging.
OAM functions of PING and TRACE for BIER IPv6 encapsulation may also
need ICMP based on BIER IPv6 encapsulation and cause ICMP response
message containing BIER option. The ability of seperating such OAM
ICMP packets from error ICMP packets caused by error is necessary for
the availability of OAM, otherwise the OAM function may fail due to
the rate-limiting of ICMP error packets.
5.4. Security caused by BIER option
This document introduces a new option used in IPv6 Destination
Options Header. An IPv6 packet with a normal IPv6 address of a
router (e.g. loopback IPv6 address of the router) as destination
address will possibly carry a BIER option.
For a router incapable of BIERv6, such BIERv6 packet will not be
processed by the procedure described in this document, but be
processed as normal IPv6 packet with unknown option, and the existing
security considerations for handling IPv6 options apply. Possible
way of handling IPv6 packets with BIER option may be send to CPU for
slow path processing, with rate-limiting, or be discarded according
to the local policy.
For a router capable of BIERv6, such BIERv6 packet MUST NOT be
forwarded, but should be processed as a normal IPv6 packet with
unknown option, or additionally and optionally be countered and
logged if the router is capable of doing so.
5.5. Applicability of IPsec
IPsec [RFC4301] uses two protocols to provide traffic security
services -- Authentication Header (AH) [RFC4302] and Encapsulating
Security Payload (ESP) [RFC4303]. Each protocol supports two modes
of use: transport mode and tunnel mode. IPsec support both unicast
and multicast. IPsec implementations MUST support ESP and MAY
support AH.
This document assume IPsec working in tunnel mode with inner IPv4 or
IPv6 multicast packet encapsulated in outer BIERv6 header and IPsec
header(s).
IPsec used with BIER IPv6 encapsulation to ensure that a BIER payload
is not altered while in transit between BFIR and BFERs. If a BFR in
between BFIR and BFERs is compromised, there is no way to prevent the
compromised BFR from making illegitimate modifications to the BIER
payload or to prevent it from misforwarding or misdelivering the
BIER-encapsulated packet, but the BFERs will detect the illegitimate
modifications to the BIER Payload (or the inner multicast data
packet). This could provide cryptographic integrity protection for
multicast data transport. This capability of IPsec comes from the
design that, the destination options header carrying the BIER header
is located before the AH or ESP and the BFR routers in between BFIR
and BFERs can process the BIER header without aware of AH or ESP.
For ESP, the Integrity Check Value (ICV) is computed over the ESP
header, Payload, and ESP trailer fields. It doesn't require the IP
or extension header for ICV calculating, and thus the change of DA
and BIER option data does not affect the function of ESP.
For AH, the Integrity Check Value (ICV) is computed over the IP or
extension header fields before the AH header, the AH header, and the
Payload. The IPv6 DA is immutable for unicast traffic in AH, and the
change of DA in BIER IPv6 forwarding for multicast traffic is
incompatible to this rule. How AH is extended to support multicast
traffic transporting through BIER IPv6 encapsulation is outside the
scope of this document.
The detailed control-plane for BIER IPv6 encapsulation IPsec function
is outside the scope of the document. Internet Key Exchange Protocol
Version 2 (IKEv2) [RFC5996] and Group Security Association (GSA)
[RFC5374] can be referred to for further studying.
6. IANA Considerations 6. IANA Considerations
6.1. BIER Option Type 6.1. BIER Option Type
Allocation is expected from IANA for a BIER Option Type codepoint Allocation is expected from IANA for a BIER Option Type codepoint
from the "Destination Options and Hop-by-Hop Options" sub-registry of from the "Destination Options and Hop-by-Hop Options" sub-registry of
the "Internet Protocol Version 6 (IPv6) Parameters" registry. The the "Internet Protocol Version 6 (IPv6) Parameters" registry. The
value 0x70 is suggested. value 0x70 is suggested.
skipping to change at page 12, line 4 skipping to change at page 16, line 19
+-------+--------+--------------------------+------------+ +-------+--------+--------------------------+------------+
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Stig Venaas for his valuable The authors would like to thank Stig Venaas for his valuable
comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda, comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda,
Toerless Eckert, Jeffrey Zhang for the helpful comments to improve Toerless Eckert, Jeffrey Zhang for the helpful comments to improve
this document. this document.
8. Contributors 8. Contributors
Gang Yan Gang Yan
Huawei Technologies Huawei Technologies
China China
Email: yangang@huawei.com Email: yangang@huawei.com
Yang(Yolanda) Xia Yang(Yolanda) Xia
Huawei Technologies Huawei Technologies
China China
Email: yolanda.xia@huawei.com Email: yolanda.xia@huawei.com
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008,
<https://www.rfc-editor.org/info/rfc5374>.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, DOI 10.17487/RFC5996, September 2010,
<https://www.rfc-editor.org/info/rfc5996>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
skipping to change at page 12, line 48 skipping to change at page 17, line 45
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
and A. Dolganow, "Multicast VPN Using Bit Index Explicit and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>. 2019, <https://www.rfc-editor.org/info/rfc8556>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-bier-ipv6-requirements] [I-D.ietf-bier-ipv6-requirements]
McBride, M., Xie, J., Dhanaraj, S., and R. Asati, "BIER McBride, M., Xie, J., Dhanaraj, S., and R. Asati, "BIER
IPv6 Requirements", draft-ietf-bier-ipv6-requirements-01 IPv6 Requirements", draft-ietf-bier-ipv6-requirements-03
(work in progress), July 2019. (work in progress), November 2019.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 Matsushima, S., and Z. Li, "SRv6 Network Programming",
Network Programming", draft-ietf-spring-srv6-network- draft-ietf-spring-srv6-network-programming-05 (work in
programming-01 (work in progress), July 2019. progress), October 2019.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
 End of changes. 16 change blocks. 
28 lines changed or deleted 266 lines changed or added

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