RE: CRH Draft Update - Security Considerations Section

["Xiejingrong (Jingrong)" <[e-mail]>]

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:[e-mail]] On Behalf Of Ron Bonica
Sent: Wednesday, May 27, 2020 6:23 AM
To: 6man <[e-mail]>; Eric Vyncke (evyncke) <[e-mail]>
Subject: CRH Draft Update - Security Considerations Section

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.
[XJR] Good to see some of my previous suggestion being considered.


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

[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.

-          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.

[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/



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

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



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.

[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 ?



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

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



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



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]


Juniper Business Use Only