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

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 14 May 2020 15:19:09 +0000

Hi Ron and authors,
I haven't found much change about the security mechanisms in the latest revision of this draft. 
So here are some questions I have so far on this aspect (based on the rev-18):

9.  Security Considerations

   Networks that process the CRH MUST NOT accept packets containing the
   CRH from untrusted sources.  Their border routers SHOULD discard
   packets that satisfy the following criteria:

   o  The packet contains a CRH

   o  The Segments Left field in the CRH has a value greater than 0

   o  The Destination Address field in the IPv6 header represents an
      interface that resides inside of the network.

   Many border routers cannot filter packets based upon the Segments
   Left value.  These border routers MAY discard packets that satisfy
   the following criteria:

   o  The packet contains a CRH

   o  The Destination Address field in the IPv6 header represents an
      interface that resides inside of the network.

[Q1] Do the words 'SHOULD' and 'MAY' mean the protection for boundary is optional? Or there is no "limited domain" boundary for the CRH ?
    If this is optional, Is it possible for a packet to be constructed and sent from internet such that it will oscillate between two CRH routers many times ?

[Q2] Does the word 'MAY' mean a router cannot filter packets based upon the SL value, but may filter packets contains a CRH ?
    Judging a packets contains a CRH means judging a packet contains a RH and "Routing Type" field == 5/6;
    Judging a packet whether the SL is greater than 0 means judging a packet contains a RH and "SL" field !=0;
    I failed to see why a router could do the first one but couldn't do the second one.
    Besides, could the above two judgements be executed on a border router if there is a HBH before the RH ?

[Q3] How to judge the "DA represents an interface that resides inside of the network"? suppose the following diagram:
    [Internet--------BorderRouter------CRHrouter1------intermediateRouters------CRHrouter2]
    A packet (SA=internet, DA=CRHrouter1) (CRH SL=1, SID[0]=CRHrouter2, SID[1]=CRHrouter1) is received by BorderRouter.
    In this case, the DA = CRHrouter1 means "an interface that resides inside of the network" ?
    If there are 1000 routers say CRHrouter1/2/.../1000, will you consider to use an IPv6 address block (like 5.1 of RFC8754) for this judgement ?

Best Regards
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, May 14, 2020 2:28 AM
To: Bob Hinden <[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: CRH and RH0

Bob,

I just posted version 16:

- tracker: https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/
- diff: https://www.ietf.org/rfcdiff?url2=draft-bonica-6man-comp-rtg-hdr-16

It removes all references to RH0 and is more explicit about operating inside of a network domain for security reasons.

I still see a use case for the 32-bit SID, so I left that in the draft.

                                                                    Ron

Juniper Business Use Only

-----Original Message-----
From: Bob Hinden <[email-masked]> 
Sent: Wednesday, May 13, 2020 1:29 PM
To: Darren Dukes (ddukes) <ddukes=[email-masked]>
Cc: Bob Hinden <[email-masked]>; Ron Bonica <[email-masked]>; 6man <[email-masked]>
Subject: Re: CRH and RH0

Hi,

> On May 13, 2020, at 10:16 AM, Darren Dukes (ddukes) <ddukes=[email-masked]> wrote:
> 
> Hi Ron,
> 
> I'm still trying to figure out where you're going with this.
> First it was SRm6, then an RH0 replacement, then not an RH0 replacement (in the 6man meeting), then it sort of is...
> 
> So I'm hoping you'll update the draft so I can understand a bit more:
> - CRH has nothing to do with RH0.
> - CRH operates only within a limited domain.

I think these are reasonable suggestions.

I also think only having one size would be helpful.

Bob

> 
> Anything else to clarify from others comments would help too.
> 
> Thanks
>   Darren
> 
>> On May 12, 2020, at 5:36 PM, Ron Bonica <[email-masked]> wrote:
>> 
>> Ole, Darren,
>> 
>> The CRH is a general purpose Routing header that operates inside of a network domain. In the sense that it is a general purpose routing header, it replaces RH0. In the sense that it is restricted to a network domain, it does not replace RH0.
>> 
>> If adding these two sentences will cause you to support the draft, or at least not object to it, I will happily add them!
>> 
>> Are these the only objections?
>> 
>>                                                                                    Ron
>> 
>> 
>> 
>> Juniper Business Use Only
>> 
>> -----Original Message-----
>> From: [email-masked] <[email-masked]>
>> Sent: Tuesday, May 12, 2020 4:38 PM
>> To: Ron Bonica <[email-masked]>
>> Cc: Darren Dukes (ddukes) <[email-masked]>; 6man <[email-masked]>
>> Subject: Re: CRH and RH0
>> 
>> [External Email. Be cautious of content]
>> 
>> 
>> Hi Ron,
>> 
>> 
>>> The answer to your question is a bit nuanced. My goals were to build a general purpose routing header that overcomes the RH0's limitations. Those being:
>>> 
>>>      - Its size
>>>      - Its security issues
>>> 
>>> Now, is that a replacement for RH0? In one way, yes. RH0 and CRH are both general purpose routing headers. In another sense, no. RH0 is meant to traverse network boundaries. But RFC 5095 taught us that letting routing header traverse network boundaries might not be a wonderful idea. So, CRH is restricted to a network domain.
>> 
>> If CRH could be a RH0 replacement, you would have to show how the tag distribution mechanism would work across the Internet?
>> RH0 was supported in every IPv6 node, given the requirement for a tag->IPv6 address (or is it forwarding method) mapping, I can't quite see how that would be done in a general enough fashion for CRH?
>> 
>> I don't think RFC5095 taught us that source routing cannot be done across the Internet.
>> In fact I don't see how the CRH draft prevents the RFC5095 attack to happen inside of the CRH limited domain.
>> Just send a packet with a list of tag#0, tag#1, tag#0, tag#1 and you have the same amplification attack.
>> 
>>> And now I return to my original question. When engineering students read the CRH RFC in 25 years, will they really care what my motivation was? Why should we burden them with this detail?
>> 
>> To the contrary. Take the motivations and intentions behind IPv6. We have spent thousands of emails trying to decode what the original intensions with EHs and their limitations were, why the minimum MTU was 1280, recently I saw a thread about the reasons for why TTL/HL and protocol/next header was swapped between v4 and v6. If your protocol is successful, the original napkin it was designed on will become legend. ;-)
>> 
>> Best regards,
>> Ole
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "qinfengwei" <[email-masked]>
Date: Fri, 15 May 2020 18:13:57 +0800

Hi Ron and authors,

As a operator, Security is one of the most important factors in whether a
solution could be implemented.
It is hoped that the security aspects will be carefully considered.

Thanks,
Fengwei Qin

-----邮件原件-----
发件人: ipv6 [mailto:[email-masked]] 代表 Xiejingrong (Jingrong)
发送时间: 2020年5月14日 23:19
收件人: Ron Bonica; Bob Hinden; Darren Dukes (ddukes)
抄送: 6man
主题: Questions regarding the security mechanisms//RE: CRH and RH0

Hi Ron and authors,
I haven't found much change about the security mechanisms in the latest
revision of this draft. 
So here are some questions I have so far on this aspect (based on the
rev-18):

[Q1] Do the words 'SHOULD' and 'MAY' mean the protection for boundary is
optional? Or there is no "limited domain" boundary for the CRH ?
    If this is optional, Is it possible for a packet to be constructed and
sent from internet such that it will oscillate between two CRH routers many
times ?

[Q2] Does the word 'MAY' mean a router cannot filter packets based upon the
SL value, but may filter packets contains a CRH ?
    Judging a packets contains a CRH means judging a packet contains a RH
and "Routing Type" field == 5/6;
    Judging a packet whether the SL is greater than 0 means judging a packet
contains a RH and "SL" field !=0;
    I failed to see why a router could do the first one but couldn't do the
second one.
    Besides, could the above two judgements be executed on a border router
if there is a HBH before the RH ?

[Q3] How to judge the "DA represents an interface that resides inside of the
network"? suppose the following diagram:
 
[Internet--------BorderRouter------CRHrouter1------intermediateRouters------
CRHrouter2]
    A packet (SA=internet, DA=CRHrouter1) (CRH SL=1, SID[0]=CRHrouter2,
SID[1]=CRHrouter1) is received by BorderRouter.
    In this case, the DA = CRHrouter1 means "an interface that resides
inside of the network" ?
    If there are 1000 routers say CRHrouter1/2/.../1000, will you consider
to use an IPv6 address block (like 5.1 of RFC8754) for this judgement ?

Best Regards
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, May 14, 2020 2:28 AM
To: Bob Hinden <[email-masked]>; Darren Dukes (ddukes)
<ddukes=[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: CRH and RH0

Bob,

It removes all references to RH0 and is more explicit about operating inside
of a network domain for security reasons.

                                                                    Ron

-----Original Message-----
From: Bob Hinden <[email-masked]> 
Sent: Wednesday, May 13, 2020 1:29 PM
To: Darren Dukes (ddukes) <ddukes=[email-masked]>
Cc: Bob Hinden <[email-masked]>; Ron Bonica <[email-masked]>;
6man <[email-masked]>
Subject: Re: CRH and RH0

Hi,

> On May 13, 2020, at 10:16 AM, Darren Dukes (ddukes)
<ddukes=[email-masked]> wrote:
> First it was SRm6, then an RH0 replacement, then not an RH0 replacement
(in the 6man meeting), then it sort of is...

Bob

>> The CRH is a general purpose Routing header that operates inside of a
network domain. In the sense that it is a general purpose routing header, it
replaces RH0. In the sense that it is restricted to a network domain, it
does not replace RH0.
>> 
>> If adding these two sentences will cause you to support the draft, or at
least not object to it, I will happily add them!
Ron
>>> The answer to your question is a bit nuanced. My goals were to build a
general purpose routing header that overcomes the RH0's limitations. Those
being:
>>> 
>>>      - Its size
>>>      - Its security issues
>>> 
>>> Now, is that a replacement for RH0? In one way, yes. RH0 and CRH are
both general purpose routing headers. In another sense, no. RH0 is meant to
traverse network boundaries. But RFC 5095 taught us that letting routing
header traverse network boundaries might not be a wonderful idea. So, CRH is
restricted to a network domain.
>> 
>> If CRH could be a RH0 replacement, you would have to show how the tag
distribution mechanism would work across the Internet?
>> RH0 was supported in every IPv6 node, given the requirement for a
tag->IPv6 address (or is it forwarding method) mapping, I can't quite see
how that would be done in a general enough fashion for CRH?
>>> And now I return to my original question. When engineering students read
the CRH RFC in 25 years, will they really care what my motivation was? Why
should we burden them with this detail?
>> 
>> To the contrary. Take the motivations and intentions behind IPv6. We have
spent thousands of emails trying to decode what the original intensions with
EHs and their limitations were, why the minimum MTU was 1280, recently I saw
a thread about the reasons for why TTL/HL and protocol/next header was
swapped between v4 and v6. If your protocol is successful, the original
napkin it was designed on will become legend. ;-)

---

From: Ron Bonica <[email-masked]>
Date: Fri, 15 May 2020 20:08:29 +0000

Fengwei, Jingrong,

Your raise excellent questions, and I will try to address them. 

In 2007,  security researchers demonstrated that Routing headers can be used attack vectors. See the following slide deck:

- http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf

Therefore, we conclude that if a network contains nodes that process the CRH, it MUST deploy ACLs at its edge. These ACLs:
	- MUST be sufficiently restrictive to filter harmful packets
	- SHOULD NOT be so restrictive that they filter harmless packets.

Therefore, the network SHOULD filter packets that satisfy all of the following criteria:

	- The Destination Address field in the IPv6 header represents an interface that resides inside of the network.
	- The packet contains a CRH
	- The Segments Left field is greater than 0

We understand that many networks cannot filter on such a granular basis. Therefore, they MAY deploy ACLs that filter a superset of the packets described above. For example, they may:

	- Filter all packets where the Destination Address field in the IPv6 header represents an interface inside of the network. (Many network already do this).
	- Filter all packets that contain a CRH and where the Destination Address field in the IPv6 header represents an interface inside of the network.
	- Filter all packets that contain a CRH

I hope that this helps.

                                                                       Ron

-----Original Message-----
From: qinfengwei <[email-masked]> 
Sent: Friday, May 15, 2020 6:14 AM
To: 'Xiejingrong (Jingrong)' <[email-masked]>; Ron Bonica <[email-masked]>; 'Bob Hinden' <[email-masked]>; 'Darren Dukes (ddukes)' <[email-masked]>
Cc: '6man' <[email-masked]>
Subject: 答复: Questions regarding the security mechanisms//RE: CRH and RH0

Hi Ron and authors,

As a operator, Security is one of the most important factors in whether a solution could be implemented.
It is hoped that the security aspects will be carefully considered.

Thanks,
Fengwei Qin

-----邮件原件-----
发件人: ipv6 [mailto:[email-masked]] 代表 Xiejingrong (Jingrong)
发送时间: 2020年5月14日 23:19
收件人: Ron Bonica; Bob Hinden; Darren Dukes (ddukes)
抄送: 6man
主题: Questions regarding the security mechanisms//RE: CRH and RH0

Hi Ron and authors,

Best Regards
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, May 14, 2020 2:28 AM
To: Bob Hinden <[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: CRH and RH0

Bob,

- tracker: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!R-fnImTVyM67P-81jr0JY3of_Uz_pmd0wjQJ3k1_gpkWaCkOaUNjSjjhrgxsyuQh$
- diff: https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-bonica-6man-comp-rtg-hdr-16__;!!NEt6yMaO-gk!R-fnImTVyM67P-81jr0JY3of_Uz_pmd0wjQJ3k1_gpkWaCkOaUNjSjjhrvB84OMK$

                                                                    Ron

-----Original Message-----
From: Bob Hinden <[email-masked]>
Sent: Wednesday, May 13, 2020 1:29 PM
To: Darren Dukes (ddukes) <ddukes=[email-masked]>
Cc: Bob Hinden <[email-masked]>; Ron Bonica <[email-masked]>; 6man <[email-masked]>
Subject: Re: CRH and RH0

Hi,

Bob

>> The CRH is a general purpose Routing header that operates inside of a
network domain. In the sense that it is a general purpose routing header, it replaces RH0. In the sense that it is restricted to a network domain, it does not replace RH0.
Ron
>>> Now, is that a replacement for RH0? In one way, yes. RH0 and CRH are
both general purpose routing headers. In another sense, no. RH0 is meant to traverse network boundaries. But RFC 5095 taught us that letting routing header traverse network boundaries might not be a wonderful idea. So, CRH is restricted to a network domain.
>> RH0 was supported in every IPv6 node, given the requirement for a
tag->IPv6 address (or is it forwarding method) mapping, I can't quite 
tag->see
how that would be done in a general enough fashion for CRH?
>>
>> I don't think RFC5095 taught us that source routing cannot be done 
>> across
the Internet.
>> Just send a packet with a list of tag#0, tag#1, tag#0, tag#1 and you 
>> have
the same amplification attack.
>>> And now I return to my original question. When engineering students 
the CRH RFC in 25 years, will they really care what my motivation was? Why should we burden them with this detail?
>> To the contrary. Take the motivations and intentions behind IPv6. We 
spent thousands of emails trying to decode what the original intensions with EHs and their limitations were, why the minimum MTU was 1280, recently I saw a thread about the reasons for why TTL/HL and protocol/next header was swapped between v4 and v6. If your protocol is successful, the original napkin it was designed on will become legend. ;-)
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!R-fnImTVyM67P-81jr0JY3of_Uz_pmd0wjQJ3k1_gpkWaCkOaUNjS
> jjhrpNNsnwO$

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!R-fnImTVyM67P-81jr0JY3of_Uz_pmd0wjQJ3k1_gpkWaCkOaUNjSjjhrpNNsnwO$
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!R-fnImTVyM67P-81jr0JY3of_Uz_pmd0wjQJ3k1_gpkWaCkOaUNjSjjhrpNNsnwO$
--------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 May 2020 17:16:26 -0300

Ron,

> 	- SHOULD NOT be so restrictive that they filter harmless packets.

I have not read your CRH draft (hence my comments might be non-sense), 
but it would seem to me that if the labels/SIDs you employ in CRH need 
mappings in the routers, and/or this functionality is turned off by 
default (i.e., support for CRH needs to be explitly enabled on the 
devices expected to use CRH), this is already a major difference and win 
over RHT0.

The main issue behind RHT0 and, for instance, IPv4 SR is that such 
functionality was enabled by default, and that all Internet nodes were 
in the position to process these packets.

If this is not the case, me, as an attacker, would have a much harder 
time exploiting CRH because I wouldn't even be able to get packets 
containing a CRH past my CE Router.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ron Bonica <[email-masked]>
Date: Fri, 15 May 2020 20:21:23 +0000

Fernando,

Good point. In order to use CRH as an attack vector, the attacker would need to know something about CRH to IPv6 address mappings.

I am assuming that the attacker has this information, either from an inside source (e.g., a disgruntled employee) or from effective guesswork.

                                                                                                                                     Ron

-----Original Message-----
From: Fernando Gont <[email-masked]> 
Sent: Friday, May 15, 2020 4:16 PM
To: Ron Bonica <[email-masked]>; qinfengwei <[email-masked]>; 'Xiejingrong (Jingrong)' <[email-masked]>; 'Bob Hinden' <[email-masked]>; 'Darren Dukes (ddukes)' <[email-masked]>
Cc: '6man' <[email-masked]>
Subject: Re: Questions regarding the security mechanisms//RE: CRH and RH0

Ron,

On 15/5/20 17:08, Ron Bonica wrote:
> - 
> https://urldefense.com/v3/__http://www.secdev.org/conf/IPv6_RH_securit
> y-csw07.pdf__;!!NEt6yMaO-gk!V5RFYkrbeopG4qEvGTKEn3T-EjmwQ85kbakl0Wbppt
> beU0S5zl5X7vOoMeAD5NxQ$
>

I have not read your CRH draft (hence my comments might be non-sense), but it would seem to me that if the labels/SIDs you employ in CRH need mappings in the routers, and/or this functionality is turned off by default (i.e., support for CRH needs to be explitly enabled on the devices expected to use CRH), this is already a major difference and win over RHT0.

The main issue behind RHT0 and, for instance, IPv4 SR is that such functionality was enabled by default, and that all Internet nodes were in the position to process these packets.

If this is not the case, me, as an attacker, would have a much harder time exploiting CRH because I wouldn't even be able to get packets containing a CRH past my CE Router.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 May 2020 17:51:06 -0300

> I am assuming that the attacker has this information, either from an inside source (e.g., a disgruntled employee) or from effective guesswork.

But also only routers that implement CRH and have populated the 
corresponding FIB could be used to bounce packets.

Whereas in the case of RHT0, any router could be used to bounce the 
packets, and I seem to recall that there were even host implementations 
that would happily honor the RHTO by effectively forwarding them.

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Fri, 15 May 2020 14:18:18 -0700

Ron,

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

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.

Tom

---

From: Ron Bonica <[email-masked]>
Date: Fri, 15 May 2020 23:15:07 +0000

Tom,

You may be right. If so, I can change the "MUST" to a "must" or some weaker language.

                                                                                Ron

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Friday, May 15, 2020 5:18 PM
To: Ron Bonica <[email-masked]>
Cc: qinfengwei <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>; Bob Hinden <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>; 6man <[email-masked]>
Subject: Re: Questions regarding the security mechanisms//RE: CRH and RH0

On Fri, May 15, 2020 at 1:09 PM Ron Bonica <rbonica=[email-masked]> wrote:
> y-csw07.pdf__;!!NEt6yMaO-gk!RXRmCM10rpZicnSnW7u-m0uiPwgTImGuFxUCtbxXoX
> RK1jT8xXDLt1kHNlNgKX1y$
>

Ron,

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

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.

Tom

> To: 'Xiejingrong (Jingrong)' <[email-masked]>; Ron Bonica 
> <[email-masked]>; 'Bob Hinden' <[email-masked]>; 'Darren 
> Dukes (ddukes)' <[email-masked]>
> - tracker: 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bon
> ica-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!R-fnImTVyM67P-81jr0JY3of_Uz_pmd
> 0wjQJ3k1_gpkWaCkOaUNjSjjhrgxsyuQh$
> - diff: 
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-bo
> nica-6man-comp-rtg-hdr-16__;!!NEt6yMaO-gk!R-fnImTVyM67P-81jr0JY3of_Uz_
> pmd0wjQJ3k1_gpkWaCkOaUNjSjjhrvB84OMK$
>
> Cc: Bob Hinden <[email-masked]>; Ron Bonica 
> <[email-masked]>; 6man <[email-masked]>
> Subject: Re: CRH and RH0
>
> Hi,
>
> >> In fact I don't see how the CRH draft prevents the RFC5095 attack 
> >> to
> happen inside of the CRH limited domain.
> >> Just send a packet with a list of tag#0, tag#1, tag#0, tag#1 and 
> >> you have
> spent thousands of emails trying to decode what the original 
> intensions with EHs and their limitations were, why the minimum MTU 
> was 1280, recently I saw a thread about the reasons for why TTL/HL and 
> protocol/next header was swapped between v4 and v6. If your protocol 
> is successful, the original napkin it was designed on will become 
> legend. ;-)
> >>
> >> Best regards,
> >> Ole
> >
> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests:
> __;!!NEt6yMaO-gk!RXRmCM10rpZicnSnW7u-m0uiPwgTImGuFxUCtbxXoXRK1jT8xXDLt
> 1kHNvnXgnUB$

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sat, 16 May 2020 06:11:33 +0000

Hi Ron,
Thanks for the prompt response.

The introduced slide deck [IPv6_RH_security-csw07.pdf] is also listed in RFC5095, reminding us to consider RFC5095 attack very carefully.
RFC6554 does have a simple text to say this "The SRH MUST NOT specify a path that visits a node more than once."
But I didn't find such text in CRH draft, please point out if I missed.
To me, even the RFC6554 has this wording and makes it an RFC, but it is just *very difficult* for an implementation in a router.
Please the 6man folks correct me if you think otherwise from a modern router implementation view.
----That's my additional thoughts to the [Q1] below. I don't think it is answered.

At a very roughly look, the CRH security mechanism seems very simple, but from a implementation view it is difficult (if not impossible):
Please consider the condition where there is an HBH (or other EHs) before RH, how the "packet contains a CRH" could be implemented.
As Tom noted, the many border routers may not be all "CRH capable" routers.
Also note that RFC5095 uses 'firewall' twice as the example of such function instead of 'router'.
Additional note: 
RFC8754 relies purely on DA and SA filtering which IMO is widely available as in BCP38. 
SRH rev-15 draft even emphasized this explicitly in section 6.2 ---- "(regardless of the presence of an SRH)".
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-15
----That's my additional thoughts to the [Q2] below. I don't think it is answered.

Best Regards
Jingrong

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]] 
Sent: Saturday, May 16, 2020 4:08 AM
To: qinfengwei <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>; 'Bob Hinden' <[email-masked]>; 'Darren Dukes (ddukes)' <[email-masked]>
Cc: '6man' <[email-masked]>
Subject: RE: Questions regarding the security mechanisms//RE: CRH and RH0

Fengwei, Jingrong,

I hope that this helps.

                                                                       Ron

-----Original Message-----
From: qinfengwei <[email-masked]>
Sent: Friday, May 15, 2020 6:14 AM
To: 'Xiejingrong (Jingrong)' <[email-masked]>; Ron Bonica <[email-masked]>; 'Bob Hinden' <[email-masked]>; 'Darren Dukes (ddukes)' <[email-masked]>
Cc: '6man' <[email-masked]>
Subject: 答复: Questions regarding the security mechanisms//RE: CRH and RH0

Hi Ron and authors,

Thanks,
Fengwei Qin

-----邮件原件-----
发件人: ipv6 [mailto:[email-masked]] 代表 Xiejingrong (Jingrong)
发送时间: 2020年5月14日 23:19
收件人: Ron Bonica; Bob Hinden; Darren Dukes (ddukes)
抄送: 6man
主题: Questions regarding the security mechanisms//RE: CRH and RH0

Hi Ron and authors,

Best Regards
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, May 14, 2020 2:28 AM
To: Bob Hinden <[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: CRH and RH0

Bob,

                                                                    Ron

-----Original Message-----
From: Bob Hinden <[email-masked]>
Sent: Wednesday, May 13, 2020 1:29 PM
To: Darren Dukes (ddukes) <ddukes=[email-masked]>
Cc: Bob Hinden <[email-masked]>; Ron Bonica <[email-masked]>; 6man <[email-masked]>
Subject: Re: CRH and RH0

Hi,

Bob

Ron
the Internet.

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sat, 16 May 2020 06:36:26 +0000

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

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

[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

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sat, 16 May 2020 06:44:24 +0000

Hi!
In my common sense, the security should not be dependent on any kind of assumption like "you can't guess out the mapping", or "you don't know the SID".
Is there any theory or IETF BCP to state such principle ?

Thanks
Jingrong

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]] 
Sent: Saturday, May 16, 2020 4:21 AM
To: Fernando Gont <[email-masked]>; qinfengwei <[email-masked]>; Xiejingrong (Jingrong) <[email-masked]>; 'Bob Hinden' <[email-masked]>; 'Darren Dukes (ddukes)' <[email-masked]>
Cc: '6man' <[email-masked]>
Subject: RE: Questions regarding the security mechanisms//RE: CRH and RH0

Fernando,

                                                                                                                                     Ron

-----Original Message-----
From: Fernando Gont <[email-masked]> 
Sent: Friday, May 15, 2020 4:16 PM
To: Ron Bonica <[email-masked]>; qinfengwei <[email-masked]>; 'Xiejingrong (Jingrong)' <[email-masked]>; 'Bob Hinden' <[email-masked]>; 'Darren Dukes (ddukes)' <[email-masked]>
Cc: '6man' <[email-masked]>
Subject: Re: Questions regarding the security mechanisms//RE: CRH and RH0

Ron,

Thanks,

---

From: S Moonesamy <[email-masked]>
Date: Sat, 16 May 2020 00:08:10 -0700

Hi Jingrong,
At 11:44 PM 15-05-2020, Xiejingrong (Jingrong) wrote:
>In my common sense, the security should not be dependent on any kind 
>of assumption like "you can't guess out the mapping", or "you don't 
>know the SID".

It is known as security by obscurity.

Regards,
S. Moonesamy

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sat, 16 May 2020 07:23:32 +0000

Good to learn.
https://en.wikipedia.org/wiki/Security_through_obscurity

Thank you!
Jingrong

-----Original Message-----
From: S Moonesamy [mailto:[email-masked]] 
Sent: Saturday, May 16, 2020 3:08 PM
To: Xiejingrong (Jingrong) <[email-masked]>; [email-masked]
Subject: RE: Questions regarding the security mechanisms//RE: CRH and RH0

Hi Jingrong,
At 11:44 PM 15-05-2020, Xiejingrong (Jingrong) wrote:
>In my common sense, the security should not be dependent on any kind of 
>assumption like "you can't guess out the mapping", or "you don't know 
>the SID".

Regards,
S. Moonesamy

---

From: Fernando Gont <[email-masked]>
Date: Sat, 16 May 2020 04:16:00 -0300

> Is there any theory or IETF BCP to state such principle ?

That's nto what I was implying.

Thanks,

---

From: Ron Bonica <[email-masked]>
Date: Sat, 16 May 2020 15:09:45 +0000

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

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

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

Thanks
Jingrong

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 16 May 2020 11:40:37 -0400

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

---

From: John Scudder <[email-masked]>
Date: Sat, 16 May 2020 19:18:27 +0000

Hi Jingrong,

As far as I can tell, although 8754 S 5.1 is very nicely written, it boils down to “use border ACLs”. Specific to this:

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

I think the “complemented per-node protection” in S 5.1 part 2 is not especially valuable, and may even be detrimental. The reasoning is as follows: if the border routers do correctly implement destination address filtering per part 1, attack traffic will already be stopped; there is no need for the source address filtering part 2 specifies. On the other hand, if the border routers do not correctly implement DA filtering, why on earth would we expect them to correctly implement SA filtering? If they don’t, then an attacker can craft their attack with forged SA to bypass SA filtering within the victim network. For this reason, I think the “complemented per-node protection” is of little value. It may be of negative value if it leads to a sense of complacency on the part of the victim.

Regards,

—John

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 16 May 2020 20:31:06 +0100

John Scudder wrote on 16/05/2020 20:18:
> network. For this reason, I think the “complemented per-node 
> protection” is of little value. It may be of negative value if it 
> leads to a sense of complacency on the part of the victim.

separate to this from a security point of view, there should be a knob
to enable CRH processing, defaulting to off.  Suggested text:

> Routers which process CRHs MUST have a configuration knob to
> control whether CRH processing is enabled or not.  The default value
> of this knob MUST be to disable CRH processing.

Nick

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 16 May 2020 16:05:17 -0400

Very good point that from a security perspective most devices may not be
able to process CRH and to that end mentioning there CRH processing MUST be
disabled by default which drastically reduces if not eliminates any attack
vector.

Also any source CRH node wanting to steer packets over the internet or
private must be knowledgeable of the DA nodes IPv6 address hop by hop along
the steered path independent of domain specific properties as CRH has
ubiquitous use cases for traffic steering.  So in that context the each
node along the steered path must have manual enablement of CRH processing
and that in itself is your security.

All best practices of ACL Ingres and egress of domain specific security
would be maintained.

So if the CRH disabled by default and has to be purposely enabled for
steering intent based flow then I don’t think you need an infrastructure
ACL on each of the nodes along the steered path.

Kind regards

Gyan

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 22 May 2020 15:36:39 +0000

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:[email-masked]] 
Sent: Saturday, May 16, 2020 11:10 PM
To: Xiejingrong (Jingrong) <[email-masked]>; Tom Herbert <[email-masked]>
Cc: qinfengwei <[email-masked]>; Bob Hinden <[email-masked]>; Darren Dukes (ddukes) <[email-masked]>; 6man <[email-masked]>
Subject: RE: Questions regarding the security mechanisms//RE: CRH and RH0

Jingrong,

                                                                  Ron

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

Thanks
Jingrong

Tom

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 22 May 2020 15:39:58 +0000

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:[email-masked]] 
Sent: Saturday, May 16, 2020 11:41 PM
To: Xiejingrong (Jingrong) <[email-masked]>; Tom Herbert <[email-masked]>; Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
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

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 22 May 2020 15:50:58 +0000

Hi John,
Please see my comment in-line below:

-----Original Message-----
From: John Scudder [mailto:[email-masked]] 
Sent: Sunday, May 17, 2020 3:18 AM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: Tom Herbert <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Questions regarding the security mechanisms//RE: CRH and RH0

Hi Jingrong,

[XJR] Yes RFC8754 boils down to "use border ACLs", but that kind of ACLs are truly available and thus make the deployment of SRH secure. The CRH border ACLs defined in current draft are not widely available, and thus make a huge surface for attacker.

[XJR] The "complemented per-node protection " is very useful for a layered security mode. Given the above weakness, the CRH may need the "complemented per-node protection" more than SRH. 

Thanks
Jingrong

Regards,

—John

---

From: John Scudder <[email-masked]>
Date: Fri, 22 May 2020 16:00:49 +0000

I’m not sure if it’s worth pursuing this much farther considering it’s not directly applicable to CRH as such. However:

On May 22, 2020, at 11:51 AM, Xiejingrong (Jingrong) <[email-masked]> wrote:
> 
> [XJR] The "complemented per-node protection " is very useful for a layered security mode.

I might be convinced if you have reasons for this that address the analysis I provided in my own message. However, a bald statement that it’s “very useful” without further support doesn’t seem too helpful. 

Regards,

—John

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 May 2020 18:11:12 +0200

Hi John,

I am afraid any new technology IETF adopts to work on should support a
basic minimum of network functionality.

And while I know some people still depend on IGP or BGP convergence in
their networks - new designs are more and more based on local
protection (node or link).

Therefore it should be in the interest of the authors of the new proposal
to describe how local protection works with their idea. Not the other way
around.

Unless you are questioning the need for local protection all together and
thinking that seconds or minutes of outage is all ok. (Which I do sincerely
hope you do not).

Many thx,
R.

On Fri, May 22, 2020 at 6:01 PM John Scudder <jgs=
[email-masked]> wrote:

> I’m not sure if it’s worth pursuing this much farther considering it’s not
> directly applicable to CRH as such. However:
>
> I might be convinced if you have reasons for this that address the
> analysis I provided in my own message. However, a bald statement that it’s
> “very useful” without further support doesn’t seem too helpful.
>
> Regards,
>
> —John

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 22 May 2020 16:16:33 +0000

Hi John,
I have read the analysis you provided in previous message.
The "very helpful" is to the layered security mode: https://en.wikipedia.org/wiki/Layered_security
To the RH security problem we are discussing:
(1) the border ACLs may fail to deploy. For example, there may be 1 border router (among 1000) is not configured correctly.
(2) a border router may be compromised (RFC8279 "If a BFIR is compromised"), the ACLs on the border router may be modified.

Thanks
Jingrong

-----Original Message-----
From: John Scudder [mailto:[email-masked]] 
Sent: Saturday, May 23, 2020 12:01 AM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: Tom Herbert <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Questions regarding the security mechanisms//RE: CRH and RH0

Regards,

—John

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 22 May 2020 18:02:47 +0100

> (2) a border router may be compromised (RFC8279 "If a BFIR is compromised"), the ACLs on the border router may be modified.

a useful second line on defence would be to recommend that all 
crh-capable nodes to drop packets containing CRHs if either the SID is 
unknown or if it comes from a source IP address outside the CRH domain. 
The perimeter of the domain will presumably already use regular iACLs to 
protect the internal infrastructure from spoofing attacks.  If your 
iACLs fail, you have bigger problems.

Good point though - something like this should go into the security 
considerations section.

Nick

---

From: John Scudder <[email-masked]>
Date: Fri, 22 May 2020 17:12:22 +0000

Hi Robert,

Your comments have no relevance to the conversation I’m having with Jingrong. You’ve completely misunderstood, we are talking about security.

—John

On May 22, 2020, at 12:11 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

I am afraid any new technology IETF adopts to work on should support a basic minimum of network functionality.

And while I know some people still depend on IGP or BGP convergence in their networks - new designs are more and more based on local protection (node or link).

Therefore it should be in the interest of the authors of the new proposal to describe how local protection works with their idea. Not the other way around.

Unless you are questioning the need for local protection all together and thinking that seconds or minutes of outage is all ok. (Which I do sincerely hope you do not).

Many thx,
R.

On Fri, May 22, 2020 at 6:01 PM John Scudder <jgs=[email-masked]<mailto:[email-masked]>> wrote:
I’m not sure if it’s worth pursuing this much farther considering it’s not directly applicable to CRH as such. However:

Regards,

—John

---

From: John Scudder <[email-masked]>
Date: Fri, 22 May 2020 17:18:44 +0000

… and in the case of such compromised border routers, why would the “layered protection” provide any value? Consider that the attacker can spoof their attack packets to have a destination in S/s *and* a source in A/a, thereby bypassing the protection described in 8754 S 5.1(2).

Layered security is a good approach but has to be applied with discipline. Part of the discipline is that one layer shouldn’t depend on the correct operation of another layer, otherwise they aren’t actually different layers. In this case, the layer that implements 5.1(2) depends on the correct operation of the layer that implements 5.1(1).

—John

> On May 22, 2020, at 12:16 PM, Xiejingrong (Jingrong) <[email-masked]> wrote:
> 
> The "very helpful" is to the layered security mode: https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Layered_security__;!!NEt6yMaO-gk!UwEFXYlQg4caPnNwR3kgg7Ue_WKW6xNMdIPi754eHcGHFdbEodJ6HIl5_S2GKQ$

---

From: John Scudder <[email-masked]>
Date: Fri, 22 May 2020 17:21:05 +0000

On May 22, 2020, at 1:02 PM, Nick Hilliard <[email-masked]> wrote:
>> The "very helpful" is to the layered security mode: https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Layered_security__;!!NEt6yMaO-gk!Tw9lbMxww481JNNLZlsb30EWBwhxUeOMmaFkiRKCTP1kWW7IWmKQhR2Zx-S1Gw$

Makes sense to me. (And is logically distinct from the 8754 case, in a good way.)

—John

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 May 2020 19:27:45 +0200

Does this mean that I can not fork such "conversation" and ask about
connectivity restoration with CRH ?

R.

On Fri, May 22, 2020 at 7:12 PM John Scudder <[email-masked]> wrote:

> Hi Robert,
>
> Your comments have no relevance to the conversation I’m having with
> Jingrong. You’ve completely misunderstood, we are talking about security.
>
> —John
>
> On May 22, 2020, at 12:11 PM, Robert Raszuk <[email-masked]> wrote:
>
> Hi John,
>
>> I’m not sure if it’s worth pursuing this much farther considering it’s
>> not directly applicable to CRH as such. However:
>>

---

From: John Scudder <[email-masked]>
Date: Fri, 22 May 2020 17:30:34 +0000

On May 22, 2020, at 1:28 PM, Robert Raszuk <[email-masked]> wrote:
> 
> Does this mean that I can not fork such "conversation" and ask about connectivity restoration with CRH ? 

Feel free to bring the topic up. Don’t feel free to misrepresent my remarks. 

—John

---

From: Ron Bonica <[email-masked]>
Date: Fri, 22 May 2020 17:35:03 +0000

Nick,

Good point. I will add this to the next draft version.

                                  Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Nick Hilliard
Sent: Friday, May 22, 2020 1:03 PM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Questions regarding the security mechanisms//RE: CRH and RH0

Xiejingrong (Jingrong) wrote on 22/05/2020 17:16:
> The "very helpful" is to the layered security mode: 
> https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Layered_secu
> rity__;!!NEt6yMaO-gk!U7r698BGtT7V-dwYc4_wiOxZBaUqgjesOlTUO5zqAP8X_Z_Mo
> 2xxz_LARBbvG53J$ To the RH security problem we are discussing:

a useful second line on defence would be to recommend that all crh-capable nodes to drop packets containing CRHs if either the SID is unknown or if it comes from a source IP address outside the CRH domain.
The perimeter of the domain will presumably already use regular iACLs to protect the internal infrastructure from spoofing attacks.  If your iACLs fail, you have bigger problems.

Good point though - something like this should go into the security considerations section.

Nick

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!U7r698BGtT7V-dwYc4_wiOxZBaUqgjesOlTUO5zqAP8X_Z_Mo2xxz_LARCViItFM$
--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Fri, 22 May 2020 17:39:45 +0000

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.

                            Ron

-----Original Message-----
From: Xiejingrong (Jingrong) <[email-masked]> 
Sent: Friday, May 22, 2020 11:40 AM
To: Joel M. Halpern <[email-masked]>; Tom Herbert <[email-masked]>; Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: Questions regarding the security mechanisms//RE: CRH and RH0

Hi Joel,

Thanks
Jingrong

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Saturday, May 16, 2020 11:41 PM
To: Xiejingrong (Jingrong) <[email-masked]>; Tom Herbert <[email-masked]>; Ron Bonica <rbonica=[email-masked]>
Cc: 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Questions regarding the security mechanisms//RE: CRH and RH0

Yours,
Joel

On 5/16/2020 2:36 AM, Xiejingrong (Jingrong) wrote:
> __;!!NEt6yMaO-gk!URSWFP3xKE9y07e2TJimSiBPJAq93q1iVHIIADPk_7peHqYHCgf2X
> 7la814ur3WJ$

---

From: Ole Troan <[email-masked]>
Date: Fri, 22 May 2020 19:48:39 +0200

> On 22 May 2020, at 19:40, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Jingrong,
> 

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 May 2020 13:54:08 -0400

Ole, not sure about one part of your message.
The CRH only gets checked when the current DA is self.
Do you mean the case where the CRH entry lookup produces a new DA 
outside the domain?  I would expect that to be checked at the control 
level rather than the packet level.  But that seems something we can 
debate once the document is adopted.

Yours,
Joel

---

From: Ron Bonica <[email-masked]>
Date: Fri, 22 May 2020 17:57:02 +0000

Ole,

These issues are generic to all routing headers. In the CRH draft, I will try to craft a security considerations section that is generic. One day, if somebody gets ambitious, they can factor that out into a separate document that applies to all Routing headers.

                                                                                 Ron

-----Original Message-----
From: Ole Troan <[email-masked]> 
Sent: Friday, May 22, 2020 1:49 PM
To: Ron Bonica <[email-masked]>
Cc: Xiejingrong (Jingrong) <[email-masked]>; Joel M. Halpern <[email-masked]>; Tom Herbert <[email-masked]>; 6man <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Questions regarding the security mechanisms//RE: CRH and RH0

Cheers
Ole

> To: Joel M. Halpern <[email-masked]>; Tom Herbert 
> <[email-masked]>; Ron Bonica <[email-masked]>
> To: Xiejingrong (Jingrong) <[email-masked]>; Tom Herbert 
> <[email-masked]>; Ron Bonica 
> <rbonica=[email-masked]>
> __;!!NEt6yMaO-gk!XUxfbzOfaCqtueW7jYWX2Ql4dSWQI65cMT7WeJ7iEKCrS9aCcc5K9
> u5czE_8FCJa$

---

From: Ole Troan <[email-masked]>
Date: Fri, 22 May 2020 20:01:20 +0200

Ron,

> On 22 May 2020, at 19:57, Ron Bonica <[email-masked]> wrote:
> 
> 

Absolutely. That’s why we don’t have any generic source routing in IP. 
Just wanted that point to be clear, since 
I think you at some point made the claim that crh resolved the attack in 5095. 

Cheers,
Ole