RE: Questions regarding the security mechanisms//RE: CRH and RH0

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

Hi Ron,

Basically I agree with your analysis. The question is:
(1) Deploy ACLs at the network edge ---- The ACL currently specified in CRH draft is NOT widely available for network edge, thus left the CRH facing almost the same security threats as RH0.
(2) Give up on Routing headers ---- Not necessary, because the RFC8754 has setup the paradigm of RH with solid security mechanism.

More detailed questions below are still unanswered [[Q1, Q2, Q3, Additional thoughts to Q1, Additional thoughts to Q2]]:
https://mailarchive.ietf.org/arch/msg/ipv6/03xzpXXRQFn0G2reYf1SS3c0208/

Frankly, I think this could be solved if you think about the security mechanism from RFC8754.
That's what I learned carefully after there were concerns about the security deployment of BIERv6:
https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-06#section-5.1

Thanks
Jingrong

-----Original Message-----
From: Ron Bonica [mailto:[e-mail]] 
Sent: Saturday, May 16, 2020 11:10 PM
To: Xiejingrong (Jingrong) <[e-mail]>; Tom Herbert <[e-mail]>
Cc: qinfengwei <[e-mail]>; Bob Hinden <[e-mail]>; Darren Dukes (ddukes) <[e-mail]>; 6man <[e-mail]>
Subject: RE: Questions regarding the security mechanisms//RE: CRH and RH0

Jingrong,

The following comments are applicable to all Routing headers, not just the SRH and CRH.

As we learned in RFC 5095, a Routing header can be used as an attack vector. Therefore, a node should not process a Routing header without some assurance that the Routing header came from a trusted source. AFAICS, there are only two ways to achieve this assurance:

	- With ACLs at the network edge
	- With cryptographic protection

Cryptographic protection at each and every segment endpoint is impractical. Therefore, we have only two choices:

	- Deploy ACLs at the network edge
	- Give up on Routing headers. Deprecate all existing Routing headers, for the same reason that we deprecated RH0. Never specify another Routing header.

                                                                  Ron



Juniper Business Use Only

-----Original Message-----
From: Xiejingrong (Jingrong) <[e-mail]> 
Sent: Saturday, May 16, 2020 2:36 AM
To: Tom Herbert <[e-mail]>; Ron Bonica <[e-mail]>
Cc: qinfengwei <[e-mail]>; Bob Hinden <[e-mail]>; Darren Dukes (ddukes) <[e-mail]>; 6man <[e-mail]>
Subject: RE: Questions regarding the security mechanisms//RE: CRH and RH0

[External Email. Be cautious of content]


<...snip the redundant text, see the in-line reply marked with [XJR]> Hi!

That raises an interesting question. Can a protocol specification have a normative MUST requirement for correctness or security that is dependent on completely external properties? If this is saying that the ACLs are implemented as part of the CRH datapath then tht might be reasonable, but if this is saying that ACLs must be deployed at every possible edge node outside of the CRH processing that doesn't seem like it could be a MUST in a protocol specification (and this might be coming close to the general but effectively useless requirement that the underlying network MUST be secure and correct for the protocol to be secure and correct).

[XJR] Good catch that "ACLs must be deployed at every possible edge node outside of the CRH processing" makes it difficult to deployable.
[XJR] But If this "MUST" is weaken to any extent, I am afraid the said RFC5095 attack could be from Internet.

Also, I think you might want to mention that AH should be used to protect the routing header when security is a concern. AH is part of the protocol suite and doesn't depend on external factors other than what's happening at the end points. Normative requirements are appropriate for security via AH.

[XJR] Agreed that AH could help to ensure the Source is from a legitimate source as RFC8754 HMAC does. But there is no mandatory AH/HMAC in this draft.
[XJR] Once an attack packet pass through the border router, there is no additional protection like the "complemented per-node protection" in RFC8754 section 5.1.

Thanks
Jingrong

Tom