Subject: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Oct 2013 06:24:06 +0100

Jari

SB> Maybe my emailer has lost the email, but this block did not seem
SB> to have been mailed out.

Early in my AD career I had to deal with the RH0 situation, and we ended up
deprecating it. Like we have, for all practical purposes, done with the similar
IPv4 mechanisms. What had initially seen as simple and useful tools turned out
to be far trickier than people believed. The RH0 deprecation was not merely an
IETF action - we deployed emergency patches to many products, worried about
people taking down networks, worried about code left in unupdated routers, and
so on.

I am not opposed to dealing with new and better mechanisms for source routing.
We've since then succeeded in defining very constrained source routing models
(RH2, for instance) that do not have the same problems.

But if we do start the work, we need to take the concerns that torpedoed
earlier designs seriously. I'll observe that the charter has no text about the
security, denial-of-service, or perimeter security concerns. It also talks
about cross-AS designs. And it paints a very powerful, flexible model that
supports a number of different applications. The combination of having
something that doesn't open up all kinds of vulnerabilities and is still
flexible is particularly worrying.

SB> I think perhaps you mean challenging, or useful? Certeainly
SB> providing the capability with adequate security would be very
SB> welcome by many operators.

SB> Currently the most developed work is MPLS, and that has exactly
SB> the same security model as MPLS has today, i.e. no new
SB> security vulnerabilities are introduced in the MPLS case.
SB> The expection is that a similar security model, i.e. strict
SB> ingress policing, encapsulation and address management
SB> would provide a similar level of security for IPv6
SB>
SB> I think you are looking for some text of the form:
SB>
SB> For each data plane technology that SPRING specifies, a security
SB> analysis must be provided showing how protection is provided
SB> against an attacker disrupting the network by maliciously
SB> injecting SPRING packets.
SB>
SB> Would that address your concern?

I'd like to understand what is our plan to address this and and I'd like to see
some words in the charter text to talk about this aspect.

Also, this text:

"Source-based routing mechanisms have previously been
specified for network protocols, but have not seen
widespread adoption other than in MPLS traffic engineering.
These applications may require greater flexibility and
per packet source imposed routing than can be achieved
through the use of the previously defined methods."

seems like it is saying that the lack of flexibility caused the mechanisms to
be not used. I don't think that is what happened. It was more about the
security headaches that they caused to network managers...

SB> No the text is saying that SR has not seen wide deployment
SB> other than in MPLS traffic engineering, but there are new
SB> applications that people now wish to deploy that would
SB> benefit from SR.

*Comment (2013-10-09)*

A colleague commented that service chaining is not listed as a motivation.
Should be it be?

SB> It is not precluded. We only give examples and if someone wants to
SB> propose an SC use case they are welcome.

This text seemed somehow odd:

   "The SPRING working group will not work on any
   mechanisms for use in networks that forward IPv4 packets."

Did you mean that the mechanisms can only work in v6-only networks, or that the
mechanisms support only v6 traffic? I think you want the latter, not the
former...

SB> Yes, SPRING intend to do MPLS and IPv6
SB> We did not find anyone wanting to do IPv4, but just in case.

- Stewart

---

From: Thomas Narten <[email-masked]>
Date: Thu, 10 Oct 2013 09:54:44 -0400

FWIW, I agree with Jari's base observation about the challenges of
source routing in IPv6 (and IPv4).

I think a key point is that with IPv6, we are talking (potentially)
end-to-end exposure of an attack vector. You can have arbitrary end
nodes anywhere on the Internet injecting traffic that potentially
directly invokes or impacts source routing. In contrast, one can view
MPLS as an L2 technology below IP. That means it's deployed in a much
more restricted setting and a normal sender of TCP/IP has a much more
restricted attack vector for doing anything that impacts MPLS directly
(this is key diffference). That means the threat surface for attacks
on MPLS are very different than for IPv6 more generally.

What has torpedoed source routing in IP is precisely that it is done
at the IP level, where it's difficult to prevent arbitrary attackers
from anywhere on the Internet creating mischief.

Thomas

Stewart Bryant
<[email-masked]> writes:

> This is a multi-part message in MIME format.
> --===============0522178731649896465==
> Content-Type: multipart/alternative;
>  boundary="------------020509030304060705060505"

> This is a multi-part message in MIME format.
> --------------020509030304060705060505
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit

> --------------020509030304060705060505
> Content-Type: multipart/related;
>  boundary="------------090109020000090909080802"

> --------------090109020000090909080802
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit

> <html>
>   <head>

>     <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
>   </head>
>   <body bgcolor="#FFFFFF" text="#000000">
>     <meta http-equiv="content-type" content="text/html;
>       charset=ISO-8859-1">
>     <pre>Jari

> SB&gt; Maybe my emailer has lost the email, but this block did not seem
> SB&gt; to have been mailed out.

> SB&gt; I think perhaps you mean challenging, or useful? Certeainly
> SB&gt; providing the capability with adequate security would be very
> SB&gt; welcome by many operators.

> SB&gt; Currently the most developed work is MPLS, and that has exactly
> SB&gt; the same security model as MPLS has today, i.e. no new 
> SB&gt; security vulnerabilities are introduced in the MPLS case.
> SB&gt; The expection is that a similar security model, i.e. strict
> SB&gt; ingress policing, encapsulation and address management 
> SB&gt; would provide a similar level of security for IPv6
> SB&gt;
> SB&gt; I think you are looking for some text of the form:
> SB&gt;
> SB&gt; For each data plane technology that SPRING specifies, a security
> SB&gt; analysis must be provided showing how protection is provided
> SB&gt; against an attacker disrupting the network by maliciously
> SB&gt; injecting SPRING packets.
> SB&gt;
> SB&gt; Would that address your concern?

> SB&gt; No the text is saying that SR has not seen wide deployment
> SB&gt; other than in MPLS traffic engineering, but there are new
> SB&gt; applications that people now wish to deploy that would
> SB&gt; benefit from SR. 

> </pre>
>     <p><b>Comment (2013-10-09)</b> <img
>         src="cid:[email-masked]" alt="" height="12"
>         width="14"></p>
>     <pre>A colleague commented that service chaining is not listed as a motivation.
> Should be it be?

> SB&gt; It is not precluded. We only give examples and if someone wants to
> SB&gt; propose an SC use case they are welcome.

> SB&gt; Yes, SPRING intend to do MPLS and IPv6
> SB&gt; We did not find anyone wanting to do IPv4, but just in case.

> </pre>
>   </body>
> </html>

> --------------090109020000090909080802
> Content-Type: image/png;
>  name="comment.png"
> Content-Transfer-Encoding: base64
> Content-ID: <[email-masked]>
> Content-Disposition: inline;
>  filename="comment.png"

> iVBORw0KGgoAAAANSUhEUgAAAA4AAAAMCAYAAABSgIzaAAAA/ElEQVQoz6WSO27DMAyG0xym
> h+gFOvUI3YPMOYS7pkOBTjlBllzD74f8lC3Z1pbZ619RjYOoDYIAIUBAAz99pKjF4tFYOQLP
> r7ubSTU6nizo63sHIQRa3qKuaxRFgSzLkCQJwjCA53lwtnsbptuUUuj7Hl3XoWk4qqoCy3Ok
> aYIoiuD7PlzXNeZ/4DCMEPLXWl1Y45isobGewKUFKjWerZw32loiz5m2phqOEQSBDVLfzuf+
> BGvzOECSudXzNtpclmCMmRprRjr8fdXVxwBhzNwA75vDDC2tdRB8mQRLKQ1E55f18c1axbWg
> wmmajGWG7voMc7t3Wa61favmB+KXRaNbDO3XAAAAAElFTkSuQmCC
> --------------090109020000090909080802--

> --------------020509030304060705060505--

> --===============0522178731649896465==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline

> _______________________________________________
> status mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/status

> --===============0522178731649896465==--

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Oct 2013 16:06:46 +0100

Thomas

My point is that just because it is challenging, does not mean we
should accept the challenge if the use case is there.

What is required is charter text that sets the bar appropriately.

Stewart

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Oct 2013 19:39:23 +0300

Thomas,

> on MPLS are very different than for IPv6 more generally.

Yes - a good point. That is one of those restricted cases where it is possible to provide a reasonably secure solution.

But my understanding is that SPRING was at IPv6 layer as well as on MPLS layer… although the charter does not explicitly say it. Just that it is not IPv4…

If SPRING is expected to run at the IPv6 layer, what is the plan to contain the vulnerability?

Jari

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Oct 2013 18:34:31 +0100

On 10/10/2013 17:39, Jari Arkko wrote:
> .
The following was just posted on the STATUS list and clarifies
intended IPv6 scope.

All,

On the topic of MPLS vs IPv6 - one being L2 hence more secure then the
other (L3) I would like to observe that any decently managed network
would already today prohibit to accept any external packets which have
as destination an infrastructure address of such network. That is the
basic protection scheme against DOS/DDOS attacks to the
infrastructure.

When such packet is detected it should be dropped - not "stripped from
explicit routes" like the above charter update would tend to suggest.

As some may recall in the past we have been working on automating such
ACLs installation based in internal IGP addresses on all border
routers under same administrative domain within single AS or number of
ASes to ease operational burden. Not sure if all vendors support such
automation today.

I think what needs to be understood that segment routing is not
internet wide source routing technology. It is carefully crafted path
engineering and packet encapsulation technique within controlled set
of domains which really do not compare to the original issues and
security concerns of source routing.

Best,
R.

I could

OLD
The initial data planes that will be considered are MPLS
and IPv6.

NEW
The initial data planes that will be considered are MPLS
and IPv6 in constrained network scopes.

END

Stewart

---

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Oct 2013 16:11:53 +0300

After some off-line chatting, I have a proposal for text to be added to the charter:

There are a number of serious security concerns with source routing at the IP layer [RFC 5095].  As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to send source routed packets that get successfully processed, without being part of the negations for setting up the source routes or being able to eavesdrop legitimate source routed packets. In some networks this base level security may be complemented with other mechanisms, such as packet filtering, cryptographic security, etc.

Would this work for people? FWIW from what I can tell, the above should be relatively easily doable, short cookies in headers, etc. It would remove my main concern of accidentally turned on devices becoming a security hole. It would also help deployment, as firewalls might otherwise default to blocking all kinds of routing headers.

Jari

---

From: joel jaeggli <[email-masked]>
Date: Fri, 11 Oct 2013 10:25:50 -0700

On Oct 11, 2013, at 10:15 AM, Ted Lemon <[email-masked]> wrote:

> On Oct 11, 2013, at 9:11 AM, Jari Arkko <[email-masked]> wrote:
> WFM, although it sounds an awful lot like a flow label... :)

20 bits is not enough to put the sha1sum of my authetication token in.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Oct 2013 13:15:11 -0400

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Oct 2013 14:06:47 -0400

> 20 bits is not enough to put the sha1sum of my authetication token in.

I know, and I didn't say _exactly_ like.   :)

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 11 Oct 2013 18:22:31 +0000

Jari,

On Oct 11, 2013, at 3:11 PM, Jari Arkko wrote:
> Would this work for people?

that would work for me. 

Thanks.
s.

> FWIW from what I can tell, the above should be relatively easily doable, short cookies in headers, etc. It would remove my main concern of accidentally turned on devices becoming a security hole. It would also help deployment, as firewalls might otherwise default to blocking all kinds of routing headers.
> 
> Jari
>

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 11 Oct 2013 20:32:22 +0200

On Fri, Oct 11, 2013 at 04:11:53PM +0300, Jari Arkko wrote:
| After some off-line chatting, I have a proposal for text to be added to the charter:
| 
| There are a number of serious security concerns with source routing at the IP layer [RFC 5095].  As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to send source routed packets that get successfully processed, without being part of the negations for setting up the source routes or being able to eavesdrop legitimate source routed packets. In some networks this base level security may be complemented with other mechanisms, such as packet filtering, cryptographic security, etc.
| 
| Would this work for people? FWIW from what I can tell, the above should be relatively easily doable, short cookies in headers, etc. It would remove my main concern of accidentally turned on devices becoming a security hole. It would also help deployment, as firewalls might otherwise default to blocking all kinds of routing headers.

jari,

i do not think that packet-filtering is feasible on the default-free-zone
on the internet. - can you take off packet-filtering in favour of security cookies ?

tx,

/hannes

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 11 Oct 2013 19:52:17 +0100

> on the internet. - can you take off packet-filtering in favour of security cookies ?
Packet filtering is prefixed by such as. In some cases it may be 
feasible and better
that a cookie. I can add cookies to the list without requiring any 
particular solution
be picked at this stage. The list is just, I believe to provide 
confidence that a solution
is feasible in the various contexts.

Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 11 Oct 2013 21:14:01 +0200

> on the internet. - can you take off packet-filtering in favour of security

What is not feasible ? Do you know any DFZ AS to permit in external
packets towards their infrastructure addresses carried in the
destination IP header ?

If so let's announce those .. I am sure few folks around will be happy
to target it over the weekend and next week there will be no more ;-)

Ref of at least one way to do it: http://goo.gl/dVeI8

r.

---

From: Hannes Gredler <[email-masked]>
Date: Fri, 11 Oct 2013 21:41:20 +0200

> packets towards their infrastructure addresses carried in the

the attack vector may not just be the infra prefixes but rather
any routed IPv6 prefix that is transiting through an IPv6-SR
capable router.

all an attacker then needs to do is:

1. pick a route which transits an IPv6-SR capable node
2. add a forged extension header

voila - you can get anywhere you want in the IPv6-SR domain;

---

as much as i like the source-routing paradigm,
it really sucks in the IP data planes due to the security
hazards involved.

i fail to see how attempt #4 for IP source routing is any
better than the previous three attempts.

/hannes

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 11 Oct 2013 21:49:11 +0200

> voila - you can get anywhere you want in the IPv6-SR domain;

Not really ...

Yes it will be allowed to get into any network, however it is very
easy not to examine extension headers on such packets hence only
provide v6 transit as any DFZ would provide today without any SR
enabled.

Segment routing != source routing .. perhaps the analogy made by some
folks is really counter productive to the technology at stake. But
your points are great as those issues you bring when addressed by
subsequent drafts will make the solution much more robust for any AF
it is deployed to work with.

Many thx,
R.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Oct 2013 22:49:32 +0300

Cookies are one way to do this, but they are part of the base level security - not the complements. I don't think we should add them to the list.

Jari

On Oct 11, 2013, at 9:52 PM, Stewart Bryant <[email-masked]> wrote:

> Packet filtering is prefixed by such as. In some cases it may be feasible and better
> that a cookie. I can add cookies to the list without requiring any particular solution
> be picked at this stage. The list is just, I believe to provide confidence that a solution

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 11 Oct 2013 22:20:59 +0100

I have taken them out of the list. This is after all a list of examples
and if we discover a cookie like thing is both required and sufficiently
secure we can address that later.

Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: joel jaeggli <[email-masked]>
Date: Fri, 11 Oct 2013 17:14:19 -0700

> basic protection scheme against DOS/DDOS attacks to the
Well… not really. we have a lovely document on control-plane protection which encapsulates what a number of operators consider good if not best practice RFC 6192.

One of the recommendations there is to allow but rate limit icmp necessary for for diagnostics. In some circles, icmp is considered an OAM diagnostic function. the operative observation though is the resource consumption potential is sufficicently trivial to understand that it can be managed with rather simple policing.

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 14 Oct 2013 09:30:51 +0200

jari,

its the other way around - 
we should take-off packet filters ... they are not deployable at internet level scale,

in contrast cookie based schemes fundamentally address the
'packet injection from anywhere in the internet' problem.

/hannes

On Fri, Oct 11, 2013 at 10:49:32PM +0300, Jari Arkko wrote:
| Cookies are one way to do this, but they are part of the base level security - not the complements. I don't think we should add them to the list.
| 
| Jari
| 
| On Oct 11, 2013, at 9:52 PM, Stewart Bryant <[email-masked]> wrote:
| 
| > On 11/10/2013 19:32, Hannes Gredler wrote:
| >> On Fri, Oct 11, 2013 at 04:11:53PM +0300, Jari Arkko wrote:
| >> | After some off-line chatting, I have a proposal for text to be added to the charter:
| >> |
| >> | There are a number of serious security concerns with source routing at the IP layer [RFC 5095].  As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to send source routed packets that get successfully processed, without being part of the negations for setting up the source routes or being able to eavesdrop legitimate source routed packets. In some networks this base level security may be complemented with other mechanisms, such as packet filtering, cryptographic security, etc.
| >> |
| >> | Would this work for people? FWIW from what I can tell, the above should be relatively easily doable, short cookies in headers, etc. It would remove my main concern of accidentally turned on devices becoming a security hole. It would also help deployment, as firewalls might otherwise default to blocking all kinds of routing headers.
| >> 
| >> jari,
| >> 
| >> i do not think that packet-filtering is feasible on the default-free-zone
| >> on the internet. - can you take off packet-filtering in favour of security cookies ?
| >> 
| > Packet filtering is prefixed by such as. In some cases it may be feasible and better
| > that a cookie. I can add cookies to the list without requiring any particular solution
| > be picked at this stage. The list is just, I believe to provide confidence that a solution
| > is feasible in the various contexts.
| > 
| > Stewart
| > 
| > 
| 
| 
|

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 14 Oct 2013 09:35:57 +0200

On Fri, Oct 11, 2013 at 09:49:11PM +0200, Robert Raszuk wrote:
| > all an attacker then needs to do is:
| >
| > 1. pick a route which transits an IPv6-SR capable node
| > 2. add a forged extension header
| >
| > voila - you can get anywhere you want in the IPv6-SR domain;
| 
| Not really ...
| 
| Yes it will be allowed to get into any network, however it is very
| easy not to examine extension headers on such packets hence only
| provide v6 transit as any DFZ would provide today without any SR
| enabled.

so you are advovating that internet DFZ router MUST NOT support IPv6-SR
based forwarding as a consequence of your statement above ?

| [ ... ] But your points are great as those issues you bring when addressed by
| subsequent drafts will make the solution much more robust for any AF
| it is deployed to work with.

i am not sure those things can get fixed at a architectual
level at all, given the amount of failed attempts so far.

/hannes

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 14 Oct 2013 10:41:01 +0200

Hi Hannes,

> based forwarding as a consequence of your statement above ?

No .. not at all. DFZ routers will first check if the v6 header
belongs to infrastructure subnets. (Those will be filtered on the
edges perhaps with the exception of some heavy rate limited ICMPs - in
fact I am not sure if ICMP should support SR at all).

If the v6 header belongs to infrastructure range SID lookup will
follow if not outer v6 header will be used for forwarding (as today).

/* Now I am expecting few emails with complains ..Ohhh my ASICs can
not choose switching vector based on the outer IP header address at
line rate ;) */

> level at all, given the amount of failed attempts so far.

Do we have a list or wiki page of those "failed attempts" ? In fact so
far I think the focus has been on the charter discussion which is
quite orthogonal to the SR architecture ..

Best,
r.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Oct 2013 12:45:53 +0300

We've had some tweaks to the text in the discussion, Stewart has placed the necessary text in the charter and I'm ready to clear. Still wondering if the WG is OK or if you need more discussion.

Jari

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 14 Oct 2013 14:00:54 +0100

Jari

The latest version of the charter now has your security
text. Are you now able to clear?

- Stewart