Subject: CRH Draft Update - Security Considerations Section

From: Ron Bonica <[email-masked]>
Date: Tue, 26 May 2020 22:23:20 +0000

Folks,

During the call for adoption, Eric Vyncke and others suggested that the Security Consideration Section should be reworked.  Does the following text work for everyone.

                                          Ron

Security Considerations
--------------------------------

The CRH can be used as an attack vector. Therefore, it is necessary to filter packets:

-          At the CRH domain ingress.

-          At the node where the CRH is processed.

At the CRH domain ingress, it is necessary to filter packets that satisfy the following criterion:

-          The IPv6 Source Address represents an interface inside of the domain. (This source address is likely to be spoofed.)

It also is necessary to filter packets that satisfy all of the following criteria:

-          The IPv6 Destination Address represents an interface inside of the CRH domain.

-          The packet contains a Routing header.

-          The Routing header is a CRH.

-          The Segments Left field has a value greater than 0.

A network operator can implement an Access Control List (ACL) that filters:

-          The above-mentioned packets only

-          The above-mentioned packets as well as others

For example, the ACL can filter all packets that satisfy the following criterion:

-          The IPv6 Destination Address represents an interface inside of the CRH domain.

At each node where the CRH is processed, it is necessary to filter packets that satisfy the following criterion:

-          The IPv6 Source Address represents an interface outside of the CRH domain.

ACLs are easily supported for small numbers of seldom changing prefixes, making summarization important.

Juniper Business Use Only

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 27 May 2020 14:49:14 +0000

Hi !
I don't represent 'everyone' but only make some points of my own.
Please see inline below marked with [XJR]

Thanks
Jingrong

From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Wednesday, May 27, 2020 6:23 AM
To: 6man <[email-masked]>; Eric Vyncke (evyncke) <[email-masked]>
Subject: CRH Draft Update - Security Considerations Section

Folks,

                                          Ron

Security Considerations

-          At the node where the CRH is processed.
[XJR] Good to see some of my previous suggestion being considered.

[XJR] Seems to me more like the "CRH domain ingress" is outside-interface of limited-domain edge node ? I would assume so and please correct me if I am wrong.

[XJR] This does not answer how a "CRH domain ingress" do the filter, especially "the packet contains a Routing Header", as I have raised but haven't see the answer:

https://mailarchive.ietf.org/arch/msg/ipv6/QyaRQAjPoRExJGWLXaSXWHcMDdQ/

https://mailarchive.ietf.org/arch/msg/ipv6/03xzpXXRQFn0G2reYf1SS3c0208/

[XJR] The 'others' is not clear to me whether it is CRH desired or not.

[XJR] If this is a CRH desired example, then I have a further comment:

The Destination address represents an interface inside of the CRH domain MAY need to establish PCE/BGP session with an outside controller, will this traffic also be filtered ?

[XJR] It's not clear to me whether the filter is an intrinsic part of "CRH processing", or an independent processing module like ACL.

ACLs are easily supported for small numbers of seldom changing prefixes,

[XJR] I don't agree with this assumption. If there is a prefix change, and 1000 "CRH domain ingress" nodes need to add an ACL each, I would not think that easy.

making summarization important.
[XJR] I agree with this and would prefer to say  summarization is super important. [End]

---

From: Ron Bonica <[email-masked]>
Date: Wed, 27 May 2020 20:42:35 +0000

Hi Jingrong,

Thanks for the review. I have updated the text to address your concerns. Please tell me if the following text is sufficient.

                                         Ron

PROPOSED TEXT
----------------------

9. Security Considerations

The CRH can be used as an attack vector. Therefore, CRH deployment is restricted to limited domains.
The limited domain maintains an Access Control List (ACL) at each of its ingress nodes. The ACL filters packets containing CRH's that would otherwise be processed inside of the limited domain. Specifically, the ACL filters packets that satisfy all of the following criteria:

  *   The IPv6 Destination Address represents an interface inside of the limited domain
  *   The packet contains a Routing header
  *   The Routing header type is CRH
  *   The Routing header Segments Left field has a value greater than 0.
Some IPv6 implementations do not support granular ACLs. If the limited domain ingress node cannot filter packets based upon  Segments Left, it can filter packets that satisfy both of the following criteria:

  *   The IPv6 Destination Address represents an interface inside of the limited domain
  *   The packet contains a Routing header
  *   The Routing header type is CRH
If the limited domain ingress node cannot filter packets based upon Routing header type or Segments Left, it can filter packets that satisfy both of the following criteria:

  *   The IPv6 Destination Address represents an interface inside of the limited domain
  *   The Packet contains a Routing header
If the limited domain ingress node cannot filter based upon IPv6 extension headers, it can filter packets that satisfy the following criterion:

  *   The IPv6 address represents an interface inside of the limited domain
When a node processes a CRH, it discards the packet if:

  *   The IPv6 Source Address represents a node outside of the limited domain
  *   The CRH-FIB does not contain an entry that is represented by the CRID
ACLs deployed at the limited domain edge prevent nodes located outside of the domain from spoofing the source address of a node inside of the domain.

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of Xiejingrong (Jingrong)
Sent: Wednesday, May 27, 2020 10:49 AM
To: Ron Bonica <rbonica=[email-masked]>; 6man <[email-masked]>; Eric Vyncke (evyncke) <[email-masked]>
Subject: RE: CRH Draft Update - Security Considerations Section

[External Email. Be cautious of content]

Hi !

Thanks
Jingrong

From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Wednesday, May 27, 2020 6:23 AM
To: 6man <[email-masked]<mailto:[email-masked]>>; Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>>
Subject: CRH Draft Update - Security Considerations Section

Folks,

                                          Ron

Security Considerations

https://mailarchive.ietf.org/arch/msg/ipv6/QyaRQAjPoRExJGWLXaSXWHcMDdQ/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/QyaRQAjPoRExJGWLXaSXWHcMDdQ/__;!!NEt6yMaO-gk!WSg1q5ln2BGs3W1s1GFuDqrJ-QN-smlNYYK31frXPhe-eSlxOS8EJY9PXXzOyIN6$>

https://mailarchive.ietf.org/arch/msg/ipv6/03xzpXXRQFn0G2reYf1SS3c0208/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/03xzpXXRQFn0G2reYf1SS3c0208/__;!!NEt6yMaO-gk!WSg1q5ln2BGs3W1s1GFuDqrJ-QN-smlNYYK31frXPhe-eSlxOS8EJY9PXcLzrfao$>

---

From: John Scudder <[email-masked]>
Date: Wed, 27 May 2020 21:01:07 +0000

Hi Jingrong,

On May 27, 2020, at 10:49 AM, Xiejingrong (Jingrong) <[email-masked]<mailto:[email-masked]>> wrote:

It’s already considered best practice for networks to block packets bound for their infrastructure addresses at their borders rather than allowing the Internet at large to directly target packets to infrastructure elements. So, if anyone actually wants to deploy a controller outside of their network perimeter, they’ve already had to think through how to permit the traffic through their ACLs. There are any number of ways it could be done; I’d think it beyond the scope of this spec to document them.

Regards,

—John