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

[Thomas Narten <[e-mail]>]

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
<[e-mail]> 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

> 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


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


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


> 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&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:[e-mail]" 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.

> 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&gt; Yes, SPRING intend to do MPLS and IPv6
> SB&gt; We did not find anyone wanting to do IPv4, but just in case.

> - Stewart

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

> --------------090109020000090909080802
> Content-Type: image/png;
>  name="comment.png"
> Content-Transfer-Encoding: base64
> Content-ID: <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/status

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