Re: [Status] SPRING Charter

[Thomas Narten <[e-mail]>]

Looking at the most recent charter proposal (-15), I have the
following questions/observations:

> The SPRING working group will define procedures that 
> will allow a node to steer a packet along an explicit 
> route using information attached to the packet and
> without the need for per-path state information to be
> held at transit nodes.

Who adds these "segment routes" (or whatever we call them -- I'll call
the SRs in this message)? Can an originating end node add them, or is
their an assumption that only network nodes add them?

My assumption is that it is network nodes (not the originating hosts)
that do that. Certainly, that is the case in MPLS and for many of the
use cases (as I understand them).

When it comes to IPv6, however, the question of who is capable of
adding these "segment routes" becomes very significant. If the
originating end node can add SRs, the attack surface for exploiting
SRs becomes much more complicated and hard to defend against. And if
end nodes can add these SRs, its hard for me not to see this problem
as equivalent to source routes as IPv6 originally had them and then
deprecated. Also, architecturally, having middle boxes (including for
SR purposes) add/modify/remove headers raises pretty significant
architectural issues. IPv6 had generally not done this and frowned on
doing so. Having network nodes *add* SRs would raise questions in this
regard.

On the other hand, if only network nodes can add SRs, it also raises
the question of whether the right way to do this is by adding SRs to
the *original* packet as originated by an end host, or whether a new
outer header should be added, in which case we are tunneling within a
region where SRs are in use. A tunneling approach changes the attack
surface considerably, and probably makes it much easier to ensure that
SRs can only be originated within the domain in which they are used.

I think it would be good to clarify this in the charter, given that
the IPv6 and MPLS assumptions are so different.

Also, this item:

>  Definition of requirements and/or any new data plane 
>    encodings and procedures, required to implement 
>    the use cases. Such procedures must include the 
>    necessary security considerations.

Suggests to me that SPRING is being given the go ahead to define IPv6
mechanisms to do SR. IMO, any IPv6 protocol work should be done in
6MAN. SPRING should do requirements, etc., but IMO IPv6 protocol work
needs to be done where the IPv6 expertise is. Or at the very least
with very close coordination.

Thomas