Re: [IPv6] I-D Action: draft-ietf-6man-comp-rtg-hdr-00.txt

[Brian E Carpenter <[e-mail]>]

On 03-Jan-24 08:47, Ron Bonica wrote:
> Brian,
> 
> For the purposes of the experiment, we could forget about the inter-domain case and say that they two nodes MUST be operated by the same party.
> 
> Would that work?

Sure. Keep life simple!

     Brian

> 
>                                     Ron
> 
> 
> 
> Juniper Business Use Only
> -----Original Message-----
> From: Brian E Carpenter <[e-mail]>
> Sent: Monday, January 1, 2024 10:32 PM
> To: Ron Bonica <[e-mail]>; 6man <[e-mail]>
> Subject: Re: [IPv6] I-D Action: draft-ietf-6man-comp-rtg-hdr-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> Hi Ron,
> 
> That's really a question for a security expert. Inter-domain trust can be a pretty complex matter. Do you swap lists of trusted IP addresses with your trust partner? Or do you trust entire prefixes? Or would it be a list of FQDNs? Or does every host in my.example.com trust every host in your.example.com?
> 
> Or are you asking for a cryptographically protected trust agreement?
> 
> Regards
>      Brian
> 
> On 02-Jan-24 05:03, Ron Bonica wrote:
>> Brian,
>>
>> Good point! Could this issue be addressed by adding the following text to the beginning of the Security Considerations Section:
>>
>> "In this document, a node that processes the CRH is in the same trust domain as another node if one of the following is true:
>>
>> - Both nodes are operated by the same party.
>> - Each node is operated by a different party and the two parties maintain a special trust agreement with regard to the CRH."
>>
>>
>> Ron
>>
>>
>> Juniper Business Use Only
>> -----Original Message-----
>> From: ipv6 <[e-mail]> On Behalf Of Brian E Carpenter
>> Sent: Monday, November 20, 2023 9:35 PM
>> To: 6man <[e-mail]>
>> Subject: Re: [IPv6] I-D Action: draft-ietf-6man-comp-rtg-hdr-00.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> Hi,
>>
>> I am a bit puzzled. The vague referemce to a limited domain has gone, which is fine. But the only thing that relates to that issue is a statement in the Security Considerations that:
>>
>> "... nodes MUST discard packets containing the CRH when both of the following conditions are true:
>>
>> The Source Address does not identify an interface on a trusted node.
>>
>> The Destination Address identifies an interface on the local node."
>>
>> The term "trusted node" is not defined; in fact there is no discussion whatever of the trust model and how trust is established (and how forged source addresses are avoided). I think the chances of this draft surviving a Security Area review are very small.
>>
>> Regards
>>       Brian Carpenter
>>
>> On 21-Nov-23 14:28, [e-mail] wrote:
>>> Internet-Draft draft-ietf-6man-comp-rtg-hdr-00.txt is now available.
>>> It is a work item of the IPv6 Maintenance (6MAN) WG of the IETF.
>>>
>>>       Title:   The IPv6 Compact Routing Header (CRH)
>>>       Authors: Ron Bonica
>>>                Yuji Kamite
>>>                Andrew Alston
>>>                Daniam Henriques
>>>                Luay Jalil
>>>       Name:    draft-ietf-6man-comp-rtg-hdr-00.txt
>>>       Pages:   15
>>>       Dates:   2023-11-20
>>>
>>> Abstract:
>>>
>>>       This document describes an experiment in which two new IPv6 Routing
>>>       headers are implemented and deployed.  Collectively, they are called
>>>       the Compact Routing Headers (CRH).  Individually, they are called
>>>       CRH-16 and CRH-32.
>>>
>>>       One purpose of this experiment is to demonstrate that the CRH can be
>>>       implemented and deployed in a production network.  Another purpose is
>>>       to demonstrate that the security considerations, described in this
>>>       document, can be addressed with access control lists.  Finally, this
>>>       document encourages replication of the experiment.
>>>
>>> The IETF datatracker status page for this Internet-Draft is:
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie
>>> t
>>> f-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!Dnq7r3LfOi8q0IFBmD_-uJm0oJFDOI9e
>>> i hzWE6kwewyYJGtgDIeuhjECRYZLVPzb8J2PtvxbLPVv-F8IYGzKnGb-NvQ$
>>>
>>> There is also an HTMLized version available at:
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra
>>> f
>>> t-ietf-6man-comp-rtg-hdr-00__;!!NEt6yMaO-gk!Dnq7r3LfOi8q0IFBmD_-uJm0o
>>> J FDOI9eihzWE6kwewyYJGtgDIeuhjECRYZLVPzb8J2PtvxbLPVv-F8IYGzKOhP9rWU$
>>>
>>> Internet-Drafts are also available by rsync at:
>>> rsync.ietf.org::internet-drafts
>>>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/i-d
>>> -
>>> announce__;!!NEt6yMaO-gk!Dnq7r3LfOi8q0IFBmD_-uJm0oJFDOI9eihzWE6kwewyY
>>> J GtgDIeuhjECRYZLVPzb8J2PtvxbLPVv-F8IYGzKSF06wGc$
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests:
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
>> __;!!NEt6yMaO-gk!Dnq7r3LfOi8q0IFBmD_-uJm0oJFDOI9eihzWE6kwewyYJGtgDIeuh
>> jECRYZLVPzb8J2PtvxbLPVv-F8IYGzKhFPZpvY$
>> --------------------------------------------------------------------