Subject: Re: Segment Routing Drafts

From: Fred Baker <[email-masked]>
Date: Fri, 1 Mar 2019 14:25:59 -0800

> On Feb 27, 2019, at 8:22 PM, Ron Bonica <rbonica=[email-masked]> 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. 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?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Mar 2019 13:23:08 +1300

On 02-Mar-19 11:25, Fred Baker wrote:
> 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.
> 

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.

Which is one of the motivations for draft-carpenter-limited-domains,
of course.

    Brian

---

From: Tom Herbert <[email-masked]>
Date: Fri, 1 Mar 2019 16:39:41 -0800

> 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,
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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Mar 2019 13:55:41 +1300

> a more general OAM service. That's also true of the VPN Context

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

---

From: Tom Herbert <[email-masked]>
Date: Fri, 1 Mar 2019 17:18:30 -0800

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

---

From: Ron Bonica <[email-masked]>
Date: Mon, 4 Mar 2019 22:47:44 +0000

Fred,

The security consideration section may be a bit paranoid. As per Brian's comments, I will loosen it up.

                                                             Ron

> -----Original Message-----
> From: Fred Baker <[email-masked]>
> Sent: Friday, March 1, 2019 5:26 PM
> To: Ron Bonica <[email-masked]>
> Cc: IPv6 List <[email-masked]>
> Subject: Re: Segment Routing Drafts
> 
> 
> 
> > On Feb 27, 2019, at 8:22 PM, Ron Bonica
> <rbonica=[email-masked]> wrote:
> 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. As such, it is only useful on a small subset of the systems it
> encounters, and only in the originating network.
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 6 Mar 2019 20:23:20 +0000

Brian, Fred,

Thanks for these comments. The Security Considerations Section has been rewritten as follows:

" The OAM option can also be used in denial of service attacks. Network devices SHOULD protect themselves against such attacks by limiting the number of OAM options that they process per unit time. If the rate limit is exceeded, the network device MAY either discard the packet or continue to process the packet, ignoring the OAM option."

While the OAM option offers an alternative to the SRv6 OAM bit, its applicability is not restricted to SRv6. It is applicable in any IPv6 packet.

                                                                                                   Ron

> From: Brian E Carpenter <[email-masked]>
> Sent: Friday, March 1, 2019 7:23 PM
> To: Fred Baker <[email-masked]>; Ron Bonica
> <[email-masked]>
> >> -
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf
> >> .org_doc_draft-2Dbonica-2D6man-
> 2Doam_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0
> >> UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8
> >> &m=fA-
> M3FuAMPPT1Vz39C2CSoahbM305dnBjaZxsUnSkw8&s=UrTODtxAc6CDYfNq
> asws
> >> GetVveWmZuh3Iy5UCVRnOxc&e=
> >
> > 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.
> 
> 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").
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_rfc8402-23page-
> 2D6&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=fA-
> M3FuAMPPT1Vz39C2CSoahbM305dnBjaZxsUnSkw8&s=Bg0e57opW73bkN5
> KGBqF0IB31ou5hvoNF9hvaf6HKSM&e=)
> Which is one of the motivations for draft-carpenter-limited-domains, of
> course.
> 
>     Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 8 Mar 2019 19:22:37 +0900

Having it generally useful is a plus. What would help me is a vision, probably a few paragraphs, about how it is expected to be used. For example, I would presume that the target system is expected to maintain some counters and dump them on command. Thinking through the security implications, so now I have a flood dumping those counters, and I can determine which systems seem to be seeing a lot of traffic. They might be interesting targets...

> On Mar 7, 2019, at 5:23 AM, Ron Bonica <[email-masked]> wrote:
> 
> Brian, Fred,
> 

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Ron Bonica <[email-masked]>
Date: Mon, 11 Mar 2019 19:37:27 +0000

Fred,

Look for this in the next draft version.

In the case of counters, the counters would be dumped periodically or on command. But the command would not come from the forwarding plane. It would come from a network management station.

                              Ron

> Sent: Friday, March 8, 2019 5:23 AM
> Cc: Brian E Carpenter <[email-masked]>; IPv6 List
> <[email-masked]>
> Having it generally useful is a plus. What would help me is a vision, probably a
> few paragraphs, about how it is expected to be used. For example, I would
> presume that the target system is expected to maintain some counters and
> dump them on command. Thinking through the security implications, so now I
> have a flood dumping those counters, and I can determine which systems
> seem to be seeing a lot of traffic. They might be interesting targets...
> 
> > " The OAM option can also be used in denial of service attacks. Network
> devices SHOULD protect themselves against such attacks by limiting the
> number of OAM options that they process per unit time. If the rate limit is
> exceeded, the network device MAY either discard the packet or continue to
> process the packet, ignoring the OAM option."
> >
> > While the OAM option offers an alternative to the SRv6 OAM bit, its
> applicability is not restricted to SRv6. It is applicable in any IPv6 packet.
> >
> >
> > Ron
> >
> >
> >> considerations) is a reason the packet should not be permitted to
> >> enter aa subsequent network.
> >>
> >> 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
> >> 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
> The fact that there is a highway to hell and a stairway to heaven is an
> interesting comment on projected traffic volume...