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

> On 22 May 2020, at 19:40, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
> 
> Jingrong,
> 
> Fair enough. In the next draft version, I will adopt Nick Hilliard's suggestion. Any node processing the CRH will drop the packet:
> 
> - If it cannot resolve the SID
> - If the source address represents a node outside of the network.

Or a destination address outside the controlled domain unless it’s the last hop. 
And also with a caveat that CRH does not resolve the attack described in rfc5095 and all nodes being allowed to insert the RH must be trusted.
Or something along those lines. 

Cheers 
Ole

> 
>                            Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: Xiejingrong (Jingrong) <xiejingrong@huawei.com> 
> Sent: Friday, May 22, 2020 11:40 AM
> To: Joel M. Halpern <jmh@joelhalpern.com>; Tom Herbert <tom@herbertland.com>; Ron Bonica <rbonica@juniper.net>
> Cc: 6man <6man@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
> Subject: RE: Questions regarding the security mechanisms//RE: CRH and RH0
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Joel,
> 
> "The CRH security requirements are almost the same security criteria we accepted (and the Security ADs accepted) for SRH."
> No, they are different completely.
> 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.
> 
> Thanks
> Jingrong
> 
> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: Saturday, May 16, 2020 11:41 PM
> To: Xiejingrong (Jingrong) <xiejingrong@huawei.com>; Tom Herbert <tom@herbertland.com>; Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
> Cc: 6man <6man@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
> Subject: Re: Questions regarding the security mechanisms//RE: CRH and RH0
> 
> Maybe I am confused, but theCRH security requirements are almost the same security criteria we accepted (and the Security ADs accepted) for SRH.  These objections would apply equally to SRH.
> 
> Yours,
> Joel
> 
>> On 5/16/2020 2:36 AM, Xiejingrong (Jingrong) wrote:
>> <...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
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
>> __;!!NEt6yMaO-gk!URSWFP3xKE9y07e2TJimSiBPJAq93q1iVHIIADPk_7peHqYHCgf2X
>> 7la814ur3WJ$
>> --------------------------------------------------------------------
>> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------