Re: Segment Routing Drafts

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

On 02-Mar-19 13:39, Tom Herbert wrote:
> On Fri, Mar 1, 2019 at 4:23 PM Brian E Carpenter
> <[e-mail]> wrote:
>>
>> On 02-Mar-19 11:25, Fred Baker wrote:
>>>
>>>
>>>> On Feb 27, 2019, at 8:22 PM, Ron Bonica <rbonica=[e-mail]> wrote:
>>>> - https://datatracker.ietf.org/doc/draft-bonica-6man-oam/
>>>
>>> I read this draft, and was immediately puzzled. The OAM option is useful if and only if it is implemented and configured, and (per the security considerations) is a reason the packet should not be permitted to enter aa subsequent network.
>>
>> The text is confusing. It says:
>>
>>    Network operators should block packets containing these extension
>>    headers at their boundary.
>>
>> I hope that that is meant to say:
>>
>>    Network operators should block packets containing the OAM option
>>    at their boundary.
>>
>> Because clearly it is way out of scope for this draft to address
>> firewall recommendations in general (which anyway are covered by
>> draft-ietf-opsec-ipv6-eh-filtering, currently "Waiting_for_AD_Go-Ahead").
>>
>>> As such, it is only useful on a small subset of the systems it encounters, and only in the originating network.
>>>
>>> Am I reading this correctly?
>>
>> Well, if it is intended as part of the segment routing specs,
>> that needs to be stated in the draft. If so, it presumably inherits
>> the property of segment routing that it only works within a Segment
>> Routing Domain (https://tools.ietf.org/html/rfc8402#page-6)
>> and the OAM option would be blocked at the domain boundary.
>>
> 
> Hi Brian,
> 
> I don't see how facility is specific to segment routing. It seems like
> a more general OAM service. That's also true of the VPN Context
> Information Option.

That's possible, but I'm going by Ron's cover note. It doesn't change
my comment or Fred's very much though: if there isn't an SR domain
boundary, the text clearly assume there is some sort of boundary
where packets might be dropped.
> 
>> Which is one of the motivations for draft-carpenter-limited-domains,
>> of course.
>>
> As opposed to relying on an external firewall that may or may not
> exist or being correctly configured to enforce a limited domain, I
> suggest that the source itself should be responsible to decide whether
> it's safe and feasible to use this option or any extension header to
> some destination. Note that if the extension header is causing
> problems, it's only the source that will be able to detect the problem
> and take action (e.g. only the source node would receive an ICMP error
> caused by an extension header).

Or it would simply disappear into black hole. But basically I agree,
the source (and the boundary node that might drop packets) needs to
know what it's doing. Exactly why the limited-domains draft has
these requirements:
 
>>    7.  Verify Peer.  A node must be able to verify whether another node
>>        is a member of the domain.
>> 
>>    8.  Verify Role.  A node must be able to learn the verified role of
>>        another node.  In particular, it must be possible for a node to
>>        find boundary nodes (interfacing to the Internet).

   Brian