Re: Segment Routing Drafts

[Tom Herbert <[e-mail]>]

On Fri, Mar 1, 2019 at 4:55 PM Brian E Carpenter
<[e-mail]> wrote:
>
> 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).
>
True, but then I don't understand why these particular options
couldn't be exposed beyond a limited domain to the Internet. Claming
the scope as requirement would be restricting the potential value of
the feature I think. Suppose for instance that I am have trouble
reaching a node on the Internet. If I could attach OAM directives to
packets destined for the Internet then I can at least get some in-situ
measurements about what is happening in my local network. The only
alternative I see would be to encapsulate packets and tunnel then
across the domain to an egress point, but then the act of tunneling
can completely change the traffic flow and obscure the underlying
issue. What we really want in cases like this is a means in insert
options that are directed to the local network (domain), but are
otherwise transparent outside of the domain (FAST is designed along
these lines).

Tom

>    Brian