Subject: [Status] SPRING Charter

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

Version 12 of the charter text has Jari's security text
with Hannes' addition of cookies as a method to be
considered.

I have modified the OAM/Management text to be

o Specify OAM the mechanisms needed to support SPRING

o Publish SPRING management requirements document.

Benoit, please can you take a look at the above and
if this is still not what you are looking for
please provide text. Once we have cleared the Blocking
comments (probably during external review), I propose
that we convert the final list to milestones per
Adrian's comment, in which case the separation is
better.

The latest text as always is at:

https://datatracker.ietf.org/doc/charter-ietf-spring/

If this satisfies Jari and Benoit's concerns I would like
to put this in external review, where it is still available
for comment to polish out any last issues.

- Stewart

---

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

Benoit

Please can you look at the latest version of the charter.

You now has your text. Are you able to clear?

Stewart

On 13/10/2013 11:29, Benoit Claise wrote:
> Stewart,
>
> The following two paragraphs are redundant
>
>     SPRING should both provide support for its use as
>     an OAM tool in SPRING enabled networks, and the
>     necessary OAM and other management tools needed to
>     manage a SPRING enabled network.
>
>     The SPRING WG should provide OAM and the
>     management needed to manage  SPRING enabled networks.
>     The SPRING protocol itself may also be used as a tool for OAM
>     in SPRING enabled networks.
>
> Keep the second one.
>
> OLD:
> NEW:
> 	o Specify_the OAM_  mechanisms needed to support SPRING.
>
> Regards, Benoit

-- 
For corporate legal information go to:

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

---

From: Benoit Claise <[email-masked]>
Date: Sun, 13 Oct 2013 12:29:15 +0200

Stewart,

Keep the second one.

OLD:

NEW:

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Oct 2013 15:11:36 +0200

Stewart,

Yes, I cleared
For the sake of completeness, one COMMENT left at 
https://datatracker.ietf.org/doc/charter-ietf-spring/ballot/#benoit-claise

Regards, Benoit

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 14 Oct 2013 23:42:45 +0100

Hi Benoit

Technically it is per packet, and I can see applications where that 
might be
useful. Not too far from your home :) an OAM back to yourself is a flow,
but you might want to explore a different path on each packet.

It would be unfortunate if we lost the generality.

Stewart

On 14/10/2013 14:11, Benoit Claise wrote:
> .

---

From: Thomas Narten <[email-masked]>
Date: Tue, 15 Oct 2013 09:46:28 -0400

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

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 15 Oct 2013 11:45:49 -0400

Thomas,

On Oct 15, 2013, at 9:46 AM, Thomas Narten <[email-masked]> wrote:

> SRs becomes much more complicated

Do you think if the document set said "a host SHALL NOT add an explicit route" it would make the attack surface less complicated? Why?

FWIW I think the draft charter addresses this concern here:

"There is an assumed trust model such that any node 
imposing an explicit route on a packet is assumed to 
be allowed to do so, however administrative and trust 
boundaries may strip explicit routes from a packet."

Some hosts may be part of the trust domain. Others may not.

--John

---

From: Thomas Narten <[email-masked]>
Date: Tue, 15 Oct 2013 14:27:48 -0400

Hi John.

> Do you think if the document set said "a host SHALL NOT add an
>  explicit route" it would make the attack surface less complicated?
>  Why?

Not at all. We all know Bad Guys don't follow the rules. If the
architecture allows for an end host to add stuff to a packet header
(like an SR) that the other nodes have to deal with, someone wanting
to exploit the system will use such a capability to do so.

On the other hand, if the architecture didn't make it possible for an
end host to do this, that would be much better. MPLS effectively
acheives this because arbitrary end hosts don't have access to the
MPLS layer. They can only generate IP packets...

Hence, I'd see a much safer/verifiable way to do this architecturally
in IPv6 if it was used in conjunction with tunneling, where the tunnel
entry/exit points were controlled by network admin.

Thomas

---

From: Mark Townsley <[email-masked]>
Date: Wed, 16 Oct 2013 14:14:53 +0300

Thomas,

> to exploit the system will use such a capability to do so.

I really don't think banking on an architectural designation of router vs. host is the best approach here. In particular when it comes to anything that resembles tunneling.

> MPLS layer. They can only generate IP packets...

If there is demand for SR beyond the traditional boundaries of an MPLS core network, it will find its way. I'd much rather develop this thoughtfully from the get-go than deal with the pressure to expand SR beyond the presumed boundaries of MPLS (as we have already had to do in the past with various MPLS over IP encapsulations). 

> entry/exit points were controlled by network admin.

I think Jari's text captures your higher-level point, without presupposing a particular solution:

"attackers will be unable to send source routed packets that get successfully 
processed, without being part of the negotiation for setting up the source routes"

- Mark

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 16 Oct 2013 12:47:45 +0000

On 10/15/13 3:46 PM, "Thomas Narten" <[email-masked]> wrote:

Thomas:

Hi!

>with very close coordination.

The charter also reads:

"Any modification of or extension to existing architectures,
data planes, or control or management plane protocols
must be carried out in the working groups responsible
for the architecture, data plane, or control or
management plane protocol being modified and in
co-ordination with this working group, but may be
done in this working group after agreement with
all the relevant WG chairs and responsible Area Directors."

So I think we're in agreement.

Thanks!

Alvaro.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 16 Oct 2013 18:16:55 +0100

> their an assumption that only network nodes add them?
My assumption is that only a "trusted" node can add them.

A few months ago I would have said that only a router could add
the SR, but the interest in network virtulazation is blurring the
line between routers and hosts.

However the architecture will need to include the facility to
segregate trusted and untrusted traffic, and my assumption
has always been that untrusted traffic will need to be
encapsulated on entry to an SR network to ensure that any
band intent is appropriately neutralized.

> use cases (as I understand them).
That is what I have seen.
> deprecated.
We really have two types of node - trusted nodes an untrusted
nodes. Consider an example other than NFV. Would it be OK
of a provider's radius server to issue such packets inside the
network. This is certainly a trusted node and it would be difficult
to justify the complexity of an intermediate router to put the
encap on. On the other hand you would be insane to allow
a BYOD on the guest network to also do so.

> Also, architecturally, having middle boxes (including for
> architectural issues.
Well tunnel headers are certainly OK, but modifying the
client header causes all sorts of problems.
> IPv6 had generally not done this and frowned on
In the native header I agree.
> SRs can only be originated within the domain in which they are used.
We agree on this point.
> the IPv6 and MPLS assumptions are so different.
Looking at John's note

> Some hosts may be part of the trust domain. Others may not.

Could we perhaps say:

"There is an assumed trust model such that any node
imposing an explicit route on a packet is assumed to
be allowed to do so. Some hosts may be part of the
trust domain, but others may not. SPRING must provide
the means to distinguish between these two classes
of host and prevent untrusted hosts from imposing
a route on its packets. Administrative and trust
boundaries may strip explicit routes from a packet."

>>   Definition of requirements and/or any new data plane
The deliverable should actually be

"Definition of requirements for any new data plane"

> with very close coordination.
Yes

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 16 Oct 2013 18:19:46 +0100

> So I think we're in agreement.
Yes, but it looks like the deliverables text is slight out of
alignment - hence my proposed slight tweek

s/and\/or/for/

Stewart

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 16 Oct 2013 13:31:55 -0400

> boundaries may strip explicit routes from a packet."

As you observe elsewhere in your note, the distinction between "hosts" and "routers" is blurry at best, and from the point of view of the trust model I think there's neither a need nor a value to draw the distinction at all. For example, a BYOD router is just as much of a potential problem as a BYOD host.

Insofar as the added text really says "all the stuff we said you have to do for a 'node' applies equally to the special class of node called 'host'", it's harmless, but it's also unnecessary. I guess one might even argue it to be mildly harmful insofar as a casual reader might suppose that if hosts are called out specially, the listed considerations don't apply to other types of node. ("The exception that proves the rule" and all that.)

I'd be inclined to leave it as you had it.

--John

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 16 Oct 2013 18:26:01 +0000

>alignment - hence my proposed slight tweek

That works for me.

Thanks!

Alvaro.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Oct 2013 21:38:50 +0300

I'd suggest that the distinction between trusted and non-trusted or host and router is not as useful as we might expect.

What I was trying to suggest with my text was specifying a requirement for a technical mechanism that helps prevent inappropriate headers from being believed. Trusted/non-trusted in itself would not be as useful, until it results in a similar specific requirement. And I fear that somewhere down the line someone would decide all we need is inside/outside security model, and I do not think that helps enough in this case.

But I don't mind the new text if the old text is still also there….

Jari

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 16 Oct 2013 20:46:11 +0200

Hi Jari,

> And I fear that somewhere down the line someone would decide all we need is
> inside/outside security model, and I do not think that helps enough in this case

For one I am not convinced that inside/outside security model is not
good enough for the problem at hand.

Is your point perhaps more focused towards clear placement of such
boundary ? If so I think it's get more involved indeed as deployment
models may vary. But once such boundary is set I am not sure why it
would not be sufficient for SR architecture.

Specifically we already have defined IGP as the carrier of SIDs. You
normally do not run IGP (passive interfaces excluded) outside of your
domain boundary. That plus ACL towards/against infrastructure
addresses IMHO should provide sufficient isolation.

Best regards,
R.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Oct 2013 22:11:12 +0300

Robert - I think we discussed this previously. One of my issues was that it is not just your well-protected network that is in danger. It is also my network with thousand machines, with one accidentally turned on to accept the new headers. The current text in the charter resolves that concern, and I'm not sure I want to have headers that wouldn't be able to do protect against this… particularly when the cost is minimal.

Jari

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 16 Oct 2013 21:28:15 +0200

If you accidentally turn on SR then you have no SIDs in your thousand
machine network to forward to hence I do not see the issue. The
packets will be forwarded to the outer destination v6 address (same as
today).

I think perhaps disconnect is that extension header is not to be a
normal v6 header however packet destination (just like today in
transit) could be regular v6 address.

It's however not the charter discussion I think ....

Many thx,
R.