Re: Segment Routing Drafts

On Fri, Mar 1, 2019 at 4:23 PM Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>
> On 02-Mar-19 11:25, Fred Baker wrote:
> >
> >
> >> On Feb 27, 2019, at 8:22 PM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> 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.

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

Tom

>     Brian
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------