Subject: draft-ietf-6man-segment-routing-header-14

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Jul 2018 20:21:01 +0000

Clarence,

For the purposes of this draft, I suggest that we remove the HMAC TLV and restrict SRv6 deployment to  walled-gardens. This will allow us to progress the current draft quickly, without working through the security issues associated with routing headers on the global internet.

Soon, we will want to address the security issues associated with routing headers on the global Internet and we may want to re-introduce the HMAC TLV then. But it is unlikely that we can address this issues in the next few weeks. This issue, and the HMAC TLV, might better be left for another draft.

The following are security issues:

1) Section 6.2.2 (Performance Impact of HMAC) says, "when present, the HMAC field need only be checked and validated by the first router of the segment routing domain, this router is named 'validating SR router'.  This leads us to ask:

- How does the validating router know that it is the validating router?
- How does a non-validating router know that a packet has already been validated?

The draft is silent regarding these questions. One possibility is that every router on the edge of the segment routing domain:

- Is a validating router
- Maintains an ACL blocking all packets that attempt to circumvent validation by it

This raises the following security issues:

- An attacker can DoS a validating router by sending it a large stream of packets with an invalid MAC. The validating router will discard all of the packets that do not pass validation, but will consume inordinate resources validating the packets.
- Given the HMAC processing procedures specified in the draft, the above mentioned ACL may be computationally expensive and may be impossible to deploy on many existing ASICs
-The HMAC processing procedures specified in version 14 may be incomplete

I think that the above-mentioned ACL looks like this:

If (the packet arrives on an untrusted interface) {
	If (the DA is a SID advertised by any node in the SR domain) {
		If (the packet includes an SRH ) {
			If (the DA is a SID advertised by the local node) {
				If (the SRH contains an HMAC TLV) {
					ProcessNextACL
				} else {
					Discard
				}
			} else {
				Discard
			}
		} else {
			Discard
		}
	} else {
		ProcessNextACL
	}
} else {
	ProcessNextACL
}

Furthermore, before validating the MAC, the validating router MUST verify that Segment List[SL+1] is equal to the IP destination address. This means that the reduced notation described in Section 4.1.1 cannot be used in some cases when the packet originates outside of the SR domain.

You may want to moves some of the functionality from the ACL into HMAC processing. But if you do that, you should describe the HMAC processing completely in the document.

                                                                  Ron

---

From: Mark Smith <[email-masked]>
Date: Tue, 10 Jul 2018 06:57:39 +1000

On Tue., 10 Jul. 2018, 06:21 Ron Bonica, <[email-masked]> wrote:

> Clarence,
>
> For the purposes of this draft, I suggest that we remove the HMAC TLV and
> restrict SRv6 deployment to  walled-gardens. This will allow us to progress
> the current draft quickly, without working through the security issues
> associated with routing headers on the global internet.
>
> Soon, we will want to address the security issues associated with routing
> headers on the global Internet and we may want to re-introduce the HMAC TLV
> then. But it is unlikely that we can address this issues in the next few
> weeks. This issue, and the HMAC TLV, might better be left for another draft.
>
> 1) Section 6.2.2 (Performance Impact of HMAC) says, "when present, the
> HMAC field need only be checked and validated by the first router of the
> segment routing domain, this router is named 'validating SR router'.  This
> leads us to ask:
>
> The draft is silent regarding these questions. One possibility is that
> every router on the edge of the segment routing domain:
>
> - Is a validating router

Stating that the SR domain MUST or SHOULD be addresses using ULA addressing
would go a long way to enforcing the domain boundary. Perhaps SR could go
further and refuse to SR process packets that do not have ULA addresses.

"Controlled domains" don't really exist on the Internet, there is plenty of
RFC1918 traffic leaking for example. The only thing possible is to try to
mitigate the effects of leaks as much as possible. Internal addressing that
is invalid on the Internet as going to be one of if not the most effective
mitigation.

Regards,
Mark.

> - An attacker can DoS a validating router by sending it a large stream of
> packets with an invalid MAC. The validating router will discard all of the
> packets that do not pass validation, but will consume inordinate resources
> validating the packets.
> - Given the HMAC processing procedures specified in the draft, the above
> mentioned ACL may be computationally expensive and may be impossible to
> deploy on many existing ASICs
> Furthermore, before validating the MAC, the validating router MUST verify
> that Segment List[SL+1] is equal to the IP destination address. This means
> that the reduced notation described in Section 4.1.1 cannot be used in some
> cases when the packet originates outside of the SR domain.
>
> You may want to moves some of the functionality from the ACL into HMAC
> processing. But if you do that, you should describe the HMAC processing
> completely in the document.
>
>                                                                   Ron
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jul 2018 12:14:42 +1200

On 10/07/2018 08:57, Mark Smith wrote:
...
> is invalid on the Internet as going to be one of if not the most effective

Interesting that you should say that. This is a topic that
needs work IMNSHO. Have a look at 
https://tools.ietf.org/html/draft-carpenter-limited-domains

    Brian

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 10 Jul 2018 14:57:55 +0000

Hi Ron, Clarence and I reviewed your question, you’ve quoted 6.2.2 without any context. 

- The draft is not silent regarding how a validating router validates the SID (see section 4.3.1.1)

- The draft is not silent on how a non-validating router knows a SID list is valid (see section 6.3.1/6.3.2).

Also, as per section 5.2 topology for A1, S3, the ACL can be as simple as:

 IF src=A1 AND dst=S3 THEN HMAC MUST be present and valid

Other interfaces may be configured with a standard Infrastructure ACL, denying traffic destined to the prefix covering segments within the SR Domain.  Any ASICs implement this today.

Darren

> On Jul 9, 2018, at 4:21 PM, Ron Bonica <[email-masked]> wrote:
> 
> Clarence,
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Jul 2018 11:07:04 -0400

If the ACL were really the one you qutoe, then there would be a myriad 
ways to sneak things through the ACL.

In part due to the choice by the authors not to use 2119 langauge, the 
document scatters requriements with no marking in several places, making 
it very hard for a reader to determine from the text what the actual 
behavioral requirements are.  The security considerations in particuylar 
are a mix of descriptive text, security requirements, and other 
behavioral requirements with security implications that belong in the 
text on the given behaviors.

In the specific case of the border enforcement of HMAC, the ACL clearly 
has to be protecting all SIDs which are allowed in (which is unlikley to 
be just one) and clearly has to be tied to the direction of the packet 
arrival, not the source address.  Depending upon what you assume for 
other ACLs, there may or may not be a need for additional checks.

As Ron alluded in his message, if the DA, SL, and segment list are not 
checked there are a number of attacks that are available even if the 
HMAC check does need to be performed.

Given that the entire HMAC mechanism is introduced to allow a behavior 
with no explicit motivation, and a violation of the general segment 
routing rule of NOT allowing external access, it would seem to benefit 
this draft and the HMAC work to simply pull the HMAC out and document 
it, and the necessary behavior to allow its use, in a separate draft. 
It is perfectly reasonable for this draft, assuming it becomes a 
standards track RFC, to sqy "block all local SIDs at the border.  Then 
another draft can relax that under specific circumstances.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Tue, 10 Jul 2018 15:01:58 -0500

> associated with routing headers on the global internet.

If this is the case, maybe TLVs can also be removed from the protocol
(AFAIK HMAC is only one defined). This would be a big simplication.
Subsequently, if HMAC TLV is needed maybe it could be in a destination
option before routing header (so it can be processed by each hop in a
routing header and such options could marked as modifiable in flight).

Tom

---

From: Ron Bonica <[email-masked]>
Date: Tue, 10 Jul 2018 18:59:22 +0000

Hi Darren,

Response inline......

> -----Original Message-----
> From: Darren Dukes (ddukes) <[email-masked]>
> Sent: Tuesday, July 10, 2018 10:58 AM
> To: Ron Bonica <[email-masked]>
> Cc: 6man <[email-masked]>
> Subject: Re: draft-ietf-6man-segment-routing-header-14
> 

Please read my original email carefully. I did not ask how the validating router validates the SID. I asked how the validating router know that it is the validating router. Section 4.3.1.1 does not address this issue.

> (see section 6.3.1/6.3.2).

Again, please read my original email carefully. I did not ask how a non-validating router knows that the SID list is valid. I asked how an non-validating router knows that a packet has already been validated. Sections 6.3.1 and 6.3.2 do not address that issue.
> Other interfaces may be configured with a standard Infrastructure ACL,
> denying traffic destined to the prefix covering segments within the SR
> Domain.  Any ASICs implement this today.
> 
Here, I agree with Joel. 

                                                                                                Ron

> headers on the global Internet and we may want to re-introduce the HMAC
> TLV then. But it is unlikely that we can address this issues in the next few
> > The draft is silent regarding these questions. One possibility is that every
> router on the edge of the segment routing domain:
> >
> > - Is a validating router
> > - Given the HMAC processing procedures specified in the draft, the
> > above mentioned ACL may be computationally expensive and may be
> > impossible to deploy on many existing ASICs -The HMAC processing
> > procedures specified in version 14 may be incomplete
> >
> > Administrative Requests:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> > CI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=1_MjQ1ThW8xkteEg88V
> >
> laf7_LcTWjyKQhp0RxMiTpWc&s=aIueqGf2trCB0SSnL6q6BXvGNwQkoihL9GH
> AUQaoQA4
> > &e=

---

From: Mark Smith <[email-masked]>
Date: Wed, 11 Jul 2018 06:49:09 +1000

> https://tools.ietf.org/html/draft-carpenter-limited-domains

I agree this is a worthy topic.

The most recent version of "Insertion of IPv6 Segment Routing Headers
in a Controlled Domain"
(draft-voyer-6man-extension-header-insertion-04) gained this
statement:

"4.2.  Destination outside the Source Domain

   Since the SRH inserted within an intermediate node MUST be removed
   when all segments within the SRH have been visited, it is not
   possible to leak the SRH to the destination outside the source
   domain."

That statement is theory, in practice, it is asserting that:

- there MUST never be no vendor bugs that will cause SRH removal to
fail (i.e. vendors MUST always write 100% bug free code)

- operators MUST never misconfigure devices such that they fail to
remove the SRH (i.e. humans MUST never suffer from human error).

- devices MUST never fail such that they fail to remove the SRH (i.e.
devices MUST always fail entirely closed).

These are not theoretical types of failures, I've seen all of these
types of failures while operating networks.

It seems to me that this is what Jon Postel was getting at with be
conservative with what you send. Try to avoid sending something that
could cause others problems. I see SRH insertion and the possible
failure of its removal to be far less conservative than tunnelling
with ULA addresses to add an SRH and to create the
closed/limited/controlled domain.

I sympathise with the tunnelling overhead concern, which is why I
question whether SR SID really needs to be 128 bits in size. A smaller
SID (e.g. 64 or 32 bits) and a simple mapping scheme into IPv6
addresses would reduce that overhead. I don't think there is a
multicast SID, so that means the 128 bit SID space is actually larger
than IPv6's address space in terms of identifying unique things.

Regards,
Mark.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 10 Jul 2018 15:21:03 -0700

Hi Mark,
you've asked whether smaller SID can be used. Appreciate if you'll look and
comment on the proposal to use 20 and 32 bits-long SIDs
<https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr-00>. Mapping,
in my opinion, comes natively from advertising nodes that use IGP-and BGP
LS extensions for segment routing.

Regards,
Greg

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 10 Jul 2018 23:28:28 +0000

Hi Joel, see Inline

> On Jul 10, 2018, at 11:07 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> If the ACL were really the one you qutoe, then there would be a myriad ways to sneak things through the ACL.
> 
> In part due to the choice by the authors not to use 2119 langauge, the document scatters requriements with no marking in several places, making it very hard for a reader to determine from the text what the actual behavioral requirements are.  The security considerations in particuylar are a mix of descriptive text, security requirements, and other behavioral requirements with security implications that belong in the text on the given behaviors.
> 
> In the specific case of the border enforcement of HMAC, the ACL clearly has to be protecting all SIDs which are allowed in (which is unlikley to be just one) and clearly has to be tied to the direction of the packet arrival, not the source address.  Depending upon what you assume for other ACLs, there may or may not be a need for additional checks.

The purpose of the example ACL is to show only the change to normal infra ACLs required to allow the SID to be processed…
Consider the example as an ACE, part of a larger ACL that subsequently denies all packets destined to the prefix covering the segments in the SR Domain.
Also consider the ACL is an input ACL (therefore tied to direction).

> 
> As Ron alluded in his message, if the DA, SL, and segment list are not checked there are a number of attacks that are available even if the HMAC check does need to be performed.

The DA contains the segment that requires the HMAC, it is checked and permitted with the ACL. The HMAC verifies the source, segment list, last entry, flags are all valid.

> 
> Given that the entire HMAC mechanism is introduced to allow a behavior with no explicit motivation

The motivation is defined in section 6.3.2.

> , and a violation of the general segment routing rule of NOT allowing external access

There is no violation, the SR domain is extended to include a node that is not directly connected.

> , it would seem to benefit this draft and the HMAC work to simply pull the HMAC out and document it, and the necessary behavior to allow its use, in a separate draft. It is perfectly reasonable for this draft, assuming it becomes a standards track RFC, to sqy "block all local SIDs at the border.  Then another draft can relax that under specific circumstances.
> 
> Yours,
> Joel
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 10 Jul 2018 23:32:19 +0000

In this draft HMAC is the only one, but others are being defined for OAM, SFC and other use cases.

Darren

On Jul 10, 2018, at 4:01 PM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Jul 9, 2018, 3:21 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Clarence,

If this is the case, maybe TLVs can also be removed from the protocol (AFAIK HMAC is only one defined). This would be a big simplication. Subsequently, if HMAC TLV is needed maybe it could be in a destination option before routing header (so it can be processed by each hop in a routing header and such options could marked as modifiable in flight).

Tom

- Is a validating router

                                                                  Ron

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 10 Jul 2018 23:38:35 +0000

Please see inline

On Jul 10, 2018, at 2:59 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Hi Darren,

Response inline......

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 10, 2018 10:58 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-ietf-6man-segment-routing-header-14

Hi Ron, Clarence and I reviewed your question, you’ve quoted 6.2.2 without
any context.

- The draft is not silent regarding how a validating router validates the SID
(see section 4.3.1.1)

Yes, I see that but I thought it is very obvious.  The answer is that someone tells it through configuration (ACL or SID instantiation) or controlplane protocol.  This document is not defining controlplane.

- The draft is not silent on how a non-validating router knows a SID list is valid
(see section 6.3.1/6.3.2).

Again, the answer is someone tells it through configuration or controlplane protocol.  This document is not defining controlplane.

Here, I agree with Joel.

                                                                                               Ron

Darren

On Jul 9, 2018, at 4:21 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Clarence,

- How does the validating router know that it is the validating router?
- How does a non-validating router know that a packet has already been
validated?

- Is a validating router
- Maintains an ACL blocking all packets that attempt to circumvent
validation by it

                                                                Ron

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Jul 2018 20:49:07 -0400

Given that the example you have provided in the email is not part of the 
draft, I guess arguing about its correctness does not help anyone. 
Simplicity is a  tricky thing at the best of times.

The text in the draft treating the creation of suitable ACLs as simple 
seems, from your comments, to rely on a number of unstated assumptions. 
Both about how border ACLs are deployed, and about how and when remote 
nodes will be allowed in.

Treating remote nodes as extensions of the domain is quite a stretch all 
by itself.  Your text correctly says it must be trusted.  But does not 
proide sufficient onstraints that would correspond to any normal 
definition of an administrative domain.

You mention  in your response checking the last entry of the SL.  I do 
not see any text in the document that does that.  I twould help, 
although as noted earlier that would require explicitly prohibiting 
reduced segment lists in these situations.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Jul 2018 20:59:53 -0400

Not defining control plane in this draft seems quite sensible.
However, even in the absence of defining the control plane, defining 
what information MUST be provided by control or management means is 
generally a good idea.  Otherwise folks are guessing what was intended. 
And making folks guess is the opposite of the point of IETF RFCs.

Yours,
Joel

On 7/10/18 7:38 PM, Darren Dukes (ddukes) wrote:
>>> From: Darren Dukes (ddukes) <[email-masked] <mailto:[email-masked]>>
>>> To: Ron Bonica <[email-masked] <mailto:[email-masked]>>
>>> Cc: 6man <[email-masked] <mailto:[email-masked]>>
>> Please read my original email carefully. I did not ask how the 
>> validating router validates the SID. I asked how the validating router 
>> know that it is the validating router. Section 4.3.1.1 does not 
>> address this issue.
> 
> Yes, I see that but I thought it is very obvious.  The answer is that 
> someone tells it through configuration (ACL or SID instantiation) or 
> controlplane protocol.  This document is not defining controlplane.
> 
>>
>>>
>> Again, please read my original email carefully. I did not ask how a 
>> non-validating router knows that the SID list is valid. I asked how an 
>> non-validating router knows that a packet has already been validated. 
>> Sections 6.3.1 and 6.3.2 do not address that issue.
> 
> Again, the answer is someone tells it through configuration or 
> controlplane protocol.  This document is not defining controlplane.
> 
>>>
>>>> [email-masked] <mailto:[email-masked]>
>>>> Administrative Requests:

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 11 Jul 2018 12:27:25 +0000

Inline

> On Jul 10, 2018, at 8:49 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Given that the example you have provided in the email is not part of the draft, I guess arguing about its correctness does not help anyone. Simplicity is a  tricky thing at the best of times.
> 
> The text in the draft treating the creation of suitable ACLs as simple seems, from your comments, to rely on a number of unstated assumptions. Both about how border ACLs are deployed, and about how and when remote nodes will be allowed in.
> 
> Treating remote nodes as extensions of the domain is quite a stretch all by itself.  Your text correctly says it must be trusted.  But does not proide sufficient onstraints that would correspond to any normal definition of an administrative domain.

I said SR Domain, not administrative domain.

> 
> You mention  in your response checking the last entry of the SL.  I do not see any text in the document that does that.  I twould help, although as noted earlier that would require explicitly prohibiting reduced segment lists in these situations.

ReRead section 6.2 of the document.  The Last Entry field is part of the HMAC.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 11 Jul 2018 05:50:24 -0700

> In this draft HMAC is the only one, but others are being defined for OAM,

Darren,

Please provide references to those. For OAM at least, I believe that
Hop-by-hop and Destination options are being defined to handle that.
What would be the need for defining options like this in a router
header also?

Thanks,
Tom

>
> Darren
>
>
> On Jul 10, 2018, at 4:01 PM, Tom Herbert <[email-masked]> wrote:
>
>
>
> If this is the case, maybe TLVs can also be removed from the protocol (AFAIK
> HMAC is only one defined). This would be a big simplication. Subsequently,
> if HMAC TLV is needed maybe it could be in a destination option before
> routing header (so it can be processed by each hop in a routing header and
> such options could marked as modifiable in flight).
>
> Tom
>
>
>>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 11 Jul 2018 06:32:00 -0700

> is invalid on the Internet as going to be one of if not the most effective
Mark,

Maybe it's more accurate to say that controlled domains do exist in
the Internet (or at least are attempted), but they don't exist in
Internet protocols. Defining Internet protocols that only have correct
operation when a long list of deployment requirements are met, like
those implied by the term "controlled domain", doesn't lead to robust
protocols.

HMAC and security are not defined for use in uncontrolled domains
anyway, they are defined for any scenario where users think they need
security. One could argue that a provider network running third party
applications or is multi-tenant may be a considered controlled domain,
but nevertheless there could be good motivation for security measures
like HMAC over routing header-- perimeter security of a controlled
domain is an antiquated notion in such networks.

Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 11 Jul 2018 10:11:42 -0400

Regarding the use of the term term domain, if you are defining the term 
SR domain as "the devices we trust to produce SR Headers and process SR 
Headers", then yes, the outside nodes are in the SR Domain.  That isa 
tautological definition.  I personally findi t a confusing definition, 
since it produces a "domain" that is not a connected space (much less a 
convex space which is usually desired.)

With regard to the protect, the "Last Entry" field of the header tells 
you where the TLVs start.  Yes, that needs to be protected.  But 
protecting that does not provide any consistency checking on the last 
entry of the SRH.

As far as I can tell, as currently defined an attacker can modify an 
externally sourced packet with an authenticated SRH by modifying the 
segments left field.  depending upon exactly what ACL is being used he 
may be able to modify the DA field as well.  Modifying the Segments Left 
field will allow him to cause a number of SRH entries to be skipped, 
thus subverting whatever purpose led to having those entries, possibly 
skipping desired intermediate services or changing traffic engineering 
decisions.

Yours,
Joel

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Jul 2018 16:54:23 +0000

Hi Tom,

Your email reflects the issue that I raised in https://trac.ietf.org/trac/6man/ticket/38. Since we both raised the issue, it probably deserves some discussion.

In SRv6, we have optional information (OI) that needs to be propagated downstream. IPv6 provides the following propagation mechanisms:

-          The HBH header propagates OI to every downstream node including the destination [1]

-          The DO header that precedes the RH propagates OI to every segment endpoint, including the ultimate destination

-          The DO header that follows the RH propagates OI to the  ultimate destination only

The SRH TLV is unlike any of these. It propagates OI to every segment endpoint, except for the ultimate destination.

So, before we begin the analysis, we can say that any OI that needs to be propagated to every segment endpoint except for the ultimate destination should be encoded in an SRH TLV. I am not sure that any such OI exists, but maybe Clarence and Darren can fill in the blanks.

The following analysis applies to other SRv6 OI:

The following are benefits of encoding in the Destination Option:

-          The OI may be generalizable. Or, said another way, the OI may be useful in packets that contain a different RH Type (e.g., the IP Mobility type or another RH type that might be specified in the future).

-          The Act and Chg bit semantics are already defined and can be leveraged.

The following are the benefits of encoding in SRH TLVs:

-          Conservation of space in the HBH and Destination Option type registry

-          Reduces effort required by those who have already deployed TLVs [2]

Clarence, Darren, can you think of any other benefits?

                                                         Ron

[1] The HBH is not really an option because so many network block it
[2] According to Section 8 of this document, there is only one pre-standard implementation of the TLV.

From: Tom Herbert <[email-masked]>
Sent: Tuesday, July 10, 2018 4:02 PM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: draft-ietf-6man-segment-routing-header-14

Tom

- Is a validating router

                                                                  Ron

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=7pfDdFr9x4UVZOuyO9BDLzCBts8K3jKCR0o_gOH7tuI&s=RPO1ugMdF986DV5TCBs5b3ZTQzljRJ5FV_HrFl94ku0&e=>
--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Jul 2018 18:37:31 +0000

Darren,

Let us all assume that controlled domains can exist on the Internet. (If we don’t make that assumption, SRv6 is dead on arrival).

The following are ways to establish controlled SRv6 domains:

1)      ACLs on the boundary

2)      Cryptographic authentication at each segment endpoint

3)      Limited ACLs and cryptographic authentication, both deployed at the boundary only

Option 1 is  simple and efficient. However, it requires the controlled domain to be contiguous. They also require every boundary router to be configured as such. As Mark Smith points out (https://mailarchive.ietf.org/arch/msg/ipv6/sYKkqfpGVdS8nr_ycZ_OFYSVNHA), when this strategy is deployed, configuration errors can have severe consequences.

Option 2 is safer, but it is both computationally and monetarily expensive.

In the SRv6 scenario that we are addressing,  the controlled domain is not contiguous. Furthermore, the cost of cryptographic authentication at each segment endpoint is cost prohibitive. Therefore, we have no choice but Option 3.

So, we need to ask what kind of invalid and potentially dangerous packets could pass through both the ACL and the cryptography. At this point, we can’t really do that analysis because the ACL is left for the reader to assume.

If the ACL is the one that you propose below, domains may be vulnerable. The HMAC covers only the IP source address, the SRH flags, the SRH last entry field, the HMAC Key-id and the segment list. Therefore, it is susceptible to attacks in which a middleman alters either the IP Destination Address or the Segments Left field. In this attack, the packet may pass the ACL and the HMAC check, but will not traverse the path intended by the source. This vulnerability could be mitigated if the limited boundary ACL ensured that Segment List[SL] equals the IP Destination Address.

There may be other security vulnerabilities and I suspect that it will take more than a week or two to discover and mitigate them.

                                                                             Ron

From: Darren Dukes (ddukes) <[email-masked]>
Sent: Tuesday, July 10, 2018 7:39 PM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: draft-ietf-6man-segment-routing-header-14

Please see inline

Hi Darren,

Response inline......

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 10, 2018 10:58 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-ietf-6man-segment-routing-header-14

                                                                                               Ron

Darren

Clarence,

- Is a validating router

                                                                Ron

&e=

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2018 08:38:42 +1200

> 2)      Cryptographic authentication at each segment endpoint

I have no doubt that if draft-carpenter-limited-domains goes
anywhere, it will involve a *generic* cryptographic solution for
domain membership and boundary definition. It's something we seem
to need in many contexts, not just segment routing. If I'm right,
that suggests trying to minimise the use of protocol-specific mechanisms.

    Brian

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 12 Jul 2018 19:00:34 +0000

Hi Tom,

https://tools.ietf.org/html/draft-ali-spring-srv6-pm-02#section-3.2
Defines a Delay Measurement SRH TLV that is only used by a specific SID Type.
https://tools.ietf.org/html/draft-li-spring-passive-pm-for-srv6-np-00#section-5.3
Similar to above, I expect there would be some merging in their future.

https://tools.ietf.org/html/draft-ali-spring-srv6-oam-01(section4.4)
https://tools.ietf.org/html/draft-brockners-inband-oam-transport-05#section-7.1
Defines a Proof of Transit TLV for SRH.

Darren

On Jul 11, 2018, at 8:50 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jul 10, 2018 at 4:32 PM, Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:
In this draft HMAC is the only one, but others are being defined for OAM,
SFC and other use cases.

Darren,

Thanks,
Tom

Darren

Clarence,

Tom

- Is a validating router

                       If (the DA is a SID advertised by the local node)
{

                                                                 Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 12 Jul 2018 19:20:55 +0000

Hi Ron, the beneficial properties of SRH TLVs are:
1 - srh tlvs may be added/deleted at each segment.
2 - srh tlvs need not be parsed at each segment (dependent on local policy per active segment).

Darren

On Jul 11, 2018, at 12:54 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tom,

                                                         Ron

From: Tom Herbert <[email-masked]<mailto:[email-masked]>>

Tom

- Is a validating router

                                                                  Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 12 Jul 2018 19:30:47 +0000

Hi Ron.

1 - It looks like there is a request to define explicitly in the document what an infra ACL must be and the protection it provides.
2 - I agree there are attack vectors with the HMAC as defined that do not appear acceptable.
  - I think including the destination address and segments left resolve those pointed out to date, this limits the HMAC to a single segment that may verify it.

The Security section needs attention as discussed in this thread.  Clarence and I have not rewritten that section so we should turn our attention there next to do 1 and 2 above and get more review of it.

Darren

On Jul 11, 2018, at 2:37 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Darren,

1)      ACLs on the boundary

                                                                             Ron

Please see inline

Hi Darren,

Response inline......

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 10, 2018 10:58 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: draft-ietf-6man-segment-routing-header-14

                                                                                               Ron

Darren

Clarence,

- Is a validating router

                                                                Ron

&e=

---

From: Ron Bonica <[email-masked]>
Date: Thu, 12 Jul 2018 19:35:16 +0000

Hi Darren,

Inline......

                        Ron

From: Darren Dukes (ddukes) <[email-masked]>
Sent: Thursday, July 12, 2018 3:21 PM
To: Ron Bonica <[email-masked]>
Cc: Tom Herbert <[email-masked]>; 6man <[email-masked]>
Subject: Re: draft-ietf-6man-segment-routing-header-14

Does this mean that the SRH length can change from segment endpoint to segment endpoint? If so, you should mention that in the document.

I think that this is also true of Destination Options.

Darren

Hi Tom,

Your email reflects the issue that I raised in https://trac.ietf.org/trac/6man/ticket/38<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_trac_6man_ticket_38&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ZPiSYr6oPT31gRraPqu5msVAaKGD_zHnn8KLhBOHMr4&s=fYM_OhZWED2N0TelvwhbsRfF36-vlhItm83tWIcERzI&e=>. Since we both raised the issue, it probably deserves some discussion.

                                                         Ron

Tom

- Is a validating router

                                                                  Ron

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=ZPiSYr6oPT31gRraPqu5msVAaKGD_zHnn8KLhBOHMr4&s=rcJXAPmfJtu-5rVSUs1u6qRQnpqL_TqNTIPgQYj-u7w&e=>

---

From: Mark Smith <[email-masked]>
Date: Fri, 13 Jul 2018 07:53:17 +1000

Hi Tom,

> On Mon, Jul 9, 2018 at 1:57 PM, Mark Smith <[email-masked]> wrote:

<snip>

> the Internet (or at least are attempted),

They do exist on the Internet, however they're brittle. They're brittle because

- either through vendor defaults or operator error, the boundary
controls aren't enabled or enabled properly or completely. The many
examples and instances of source address spoofing and leaking of
RFC1918 source addresses have been enough of an issue that mitigation
projects such as AS112 (https://www.as112.net/) and Mutually Agreed
Norms for Routing Security (https://www.manrs.org/manrs/) have been
established. In other words, it fairly widespread problem.

- regardless of how many devices there are around the boundary,
they're usually (universally?) individually a single point of failure.
I'm not aware of any instances where two boundary control devices have
been put in-line at a single domain exit point to provide a defence in
depth measure against failure to perform the boundary controlling
action.

- these domains have a default route towards the Internet. If
addressing is the entity being used apply controls, then if there is
an error in destination addresses, the default nature is to leak.

(I'm finding the term "controlled domain" to be a but strange when I
think about it. It implies that there are uncontrolled domains. Any
domain that is established is by human choice, and that means that all
domains are controlled to some extent.)

Regards,
Mark.

> but they don't exist in

---

From: Tom Herbert <[email-masked]>
Date: Thu, 12 Jul 2018 19:33:02 -0700

Mark,

Controlled domains do exist insofar as this roughly describes secured
enterprise network or a mutli-tenant cloud network needs to be secure
to protect against internal threats from third party applications or
tenants. My point is that there is no single normative definition of a
controlled domain that is usable as a requirement in a protocol
specification. So regardless of either viewpoint, I think one would
reach the same conclusion that defining an Internet protocol on the
basis that it will only be used in a controlled domain is a
contradiction of terms-- that would just be a networking protocol not
an Internet protocol.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Sat, 14 Jul 2018 07:19:24 -0700

Darren,

AFAICT, the draft only mentions that TLVs can be changed not that they
can be added or deleted. This is a significant feature that needs to
be specified as to its operation.

I believe this would have many of the same issues that inserting or
deleting extension headers would have. In particular, there is no
accountability when intermediate node changes a packet. So if some
node makes a change that subsequently causes an error in a downstream
node (like inserts a bad parameter), there is no means do determine
the source of the problem. If an ICMP error is generated the source
receives the error and maybe a pointer to the offending option, but it
would have no idea what to do with it-- there is no way to recover
from this other than calling their network operator on the phone.

Also, it needs to be clarified if adding a TLV means that an
intermediate node can change the size of the packet. That can be
problematic. Increasing packet size runs the risk of exceeding path
MTU which might not be something the source can deal with. I suppose
the idea might be that the source creates a TLV space with nothing but
padding so that intermediate nodes can write TLVs into a scratch
space?

Tom

> On Jul 11, 2018, at 12:54 PM, Ron Bonica <[email-masked]> wrote:
>
> Hi Tom,
>
> Your email reflects the issue that I raised in
> https://trac.ietf.org/trac/6man/ticket/38. Since we both raised the issue,
> it probably deserves some discussion.
>
> In SRv6, we have optional information (OI) that needs to be propagated
> downstream. IPv6 provides the following propagation mechanisms:
>
> -          The DO header that precedes the RH propagates OI to every segment
> endpoint, including the ultimate destination
> The SRH TLV is unlike any of these. It propagates OI to every segment
> endpoint, except for the ultimate destination.
>
> So, before we begin the analysis, we can say that any OI that needs to be
> propagated to every segment endpoint except for the ultimate destination
> should be encoded in an SRH TLV. I am not sure that any such OI exists, but
> maybe Clarence and Darren can fill in the blanks.
>
> -          The OI may be generalizable. Or, said another way, the OI may be
> useful in packets that contain a different RH Type (e.g., the IP Mobility
> type or another RH type that might be specified in the future).
> 1) Section 6.2.2 (Performance Impact of HMAC) says, "when present, the HMAC
> field need only be checked and validated by the first router of the segment
> routing domain, this router is named 'validating SR router'.  This leads us
> to ask:
>

---

From: Ron Bonica <[email-masked]>
Date: Sun, 15 Jul 2018 15:33:21 +0000

+1

> Sent: Saturday, July 14, 2018 10:19 AM
> To: Darren Dukes (ddukes) <[email-masked]>
> Cc: Ron Bonica <[email-masked]>; 6man <[email-masked]>
> AFAICT, the draft only mentions that TLVs can be changed not that they can
> be added or deleted. This is a significant feature that needs to be specified as
> to its operation.
> 
> I believe this would have many of the same issues that inserting or deleting
> extension headers would have. In particular, there is no accountability when
> intermediate node changes a packet. So if some node makes a change that
> subsequently causes an error in a downstream node (like inserts a bad
> parameter), there is no means do determine the source of the problem. If an
> ICMP error is generated the source receives the error and maybe a pointer
> to the offending option, but it would have no idea what to do with it-- there
> is no way to recover from this other than calling their network operator on
> the phone.
> 
> Also, it needs to be clarified if adding a TLV means that an intermediate node
> can change the size of the packet. That can be problematic. Increasing packet
> size runs the risk of exceeding path MTU which might not be something the
> source can deal with. I suppose the idea might be that the source creates a
> TLV space with nothing but padding so that intermediate nodes can write
> TLVs into a scratch space?
> 
> Tom
> 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.ietf.org_tra
> > c_6man_ticket_38&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=S8qVA1Hx0w1VNnXq6kQ1h8VJucFWhQL-
> xEVfSxV0jII&s=TkHdFwA0YlUSFzemXv-ytHhmr_LpypY2qimBMsL4LEQ&e=.
> Since we both raised the issue, it probably deserves some discussion.
> >
> > So, before we begin the analysis, we can say that any OI that needs to
> > be propagated to every segment endpoint except for the ultimate
> > destination should be encoded in an SRH TLV. I am not sure that any
> > such OI exists, but maybe Clarence and Darren can fill in the blanks.
> >
> > useful in packets that contain a different RH Type (e.g., the IP
> > Mobility type or another RH type that might be specified in the future).
> > For the purposes of this draft, I suggest that we remove the HMAC TLV
> > and restrict SRv6 deployment to  walled-gardens. This will allow us to
> > progress the current draft quickly, without working through the
> > security issues associated with routing headers on the global internet.
> >
> >
> > Soon, we will want to address the security issues associated with
> > routing headers on the global Internet and we may want to re-introduce
> > the HMAC TLV then. But it is unlikely that we can address this issues
> > in the next few weeks. This issue, and the HMAC TLV, might better be left
> for another draft.
> >
> > HMAC field need only be checked and validated by the first router of
> > the segment routing domain, this router is named 'validating SR
> > router'.  This leads us to ask:
> >
> > - An attacker can DoS a validating router by sending it a large stream
> > of packets with an invalid MAC. The validating router will discard all
> > of the packets that do not pass validation, but will consume
> > inordinate resources validating the packets.
> > Furthermore, before validating the MAC, the validating router MUST
> > verify that Segment List[SL+1] is equal to the IP destination address.
> > This means that the reduced notation described in Section 4.1.1 cannot
> > be used in some cases when the packet originates outside of the SR
> domain.
> >
> > processing. But if you do that, you should describe the HMAC
> > processing completely in the document.
> >
> >                                                                   Ron
> >
> > man_listinfo_ipv6&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> AWF2EfpHcAwrDThKP8&m=S8qVA1Hx0w1VNnXq6kQ
> > 1h8VJucFWhQL-
> xEVfSxV0jII&s=YFki71gVlHYpMTklb_BZOKyCZSkt_rVjJ0jjmMRe8FE
> > &e=
> > man_listinfo_ipv6&d=DwIBaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzo
> AWF2EfpHcAwrDThKP8&m=S8qVA1Hx0w1VNnXq6kQ
> > 1h8VJucFWhQL-
> xEVfSxV0jII&s=YFki71gVlHYpMTklb_BZOKyCZSkt_rVjJ0jjmMRe8FE
> > &e=

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Jul 2018 10:18:23 -0700

Darren,

Can you provide the rationale or motivation for #2? And if srh tlvs
need not be parsed at each segment, does that equivalently mean that
srh tlvs need not be parsed at any segment?

Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 18 Jul 2018 20:47:33 +0000

Using the hmac processing as an example. The first segment may be configured locally to inspect the tlvs for the hmac and drop packets with invalid hmac. 

The second segment in the segment list may be configured to not check the hmac. 

Thus srh tlvs need not be parsed at each segment

You are correct that, depending on local policy (ie local sid configuration),  the tlvs in an srh may not be parsed at any segment.

Darren

> On Jul 18, 2018, at 1:18 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Jul 2018 14:59:17 -0700

Darren,

I don't think that's the quite the same thing. It's reasonable that
some TLVs might only be _processed_ at certain nodes, but that doesn't
mean that they shouldn't be _parsing_ the TLV list and ignoring those
they aren't interested in. Or to put it another way, if a node
processes at least _one_ TLV then it needs to parse _all_ TLVs to see
if the one they are interested in is present. The only time that a
node could skip parsing the TLVs is when they don't implement any TLVs
at all-- but if we allow that then we know from history that many HW
implementations will choose to not bother implementing TLV processing
logic or throw it in a slow path since it's quite expensive. That
might be okay in the short term if there are no TLVs that have would
be commonly implemented nodes, but some day that might change and
retrofitting devices to efficiently support TLVs is a big challenge.

In any case, if allowing nodes to not parse TLVs is a hard
requirement, I'd suggest maybe to relax the requirements of RFC8200 to
allow intermediate destinations to ignore DestOp TLVs that appear
before before the routing header. This could be similar to how the
requirements for all intermediate nodes to parse HBH options were
relaxed. I don't think this case is exactly equivalent since HBH
options would need to be processed by anonymous nodes, but the
intermediate nodes that would need to process destination options are
made explicit in the routing header. Nevertheless, if the choice is
between introducing yet another TLV mechanism a the network layer or
trying to use the existing mechanism that would probably be obsoleted
by the new mechanism any way, then IMO the former that adapts the
existing solution is the better path.
Tom