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

[Stewart Bryant <[e-mail]>]

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