Subject: Re: [Status] Joel Jaeggli's Block on charter-ietf-spring-00-06: (with BLOCK)

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

On 10/10/2013 08:18, Joel Jaeggli wrote:
> Joel Jaeggli has entered the following ballot position for
> charter-ietf-spring-00-06: Block
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/charter-ietf-spring/
>
>
>
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
>
> I am strongly in favor of jari's, statement.
>
> I would very much like to see the charter address first why it is
> believed that now it is feasible to do this when we've been down this
> path before.
>
>
>
>
Joel,

Does any of my response to Jari address your concern?

Certainly in the case of one of the two technologies under consideration
(MPLS) there is no additional security concern. We already impose
label stacks that describe indirections on the path of a packet.

The requirement is therefore to harden any other technology to the
same extent when operating in this mode. Conceptually this should
be no worse than applying ingress filtering to a tunnel, or
executing IPFRR in an IP network.

I proposed some charter text, and the IESG of the time will determine
whether the proposed IPv6 arrangement is adequately secure.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 10 Oct 2013 15:54:01 +0100

On 10/10/2013 15:43, joel jaeggli wrote:
> On Oct 10, 2013, at 4:24 AM, Stewart Bryant <[email-masked]> wrote:
>
> somewhat
> It's a property of MPLS that you push the LSP onto a packet at ingress. so specifying the LSP aligns nicely with that model.
>
>    Initial work will focus on SPRING within in a single AS,
>    however design decisions must not preclude operation
>    of SPRING across AS boundaries.
>
> It's not just an ingress problem at point, it includes transitive trust because, using MPLS as an example and the RH0 problem as a whipping boy it's hard to do loop detection if by the time the source routed packet arrives at your spring router if half the labels are already popped off. applying policy between operators may require looking all the way down the label stack or at the entire source route rather than just at the top one/next hop and so on.
>

Of a trust model that says if the outer label/address is good the path
is good.

One application for this is where one partly owns both AS, for example
DC.

In any case I think that what you are saying is that the hurdle is high,
but that should not preclude the work.

Stewart

---

From: joel jaeggli <[email-masked]>
Date: Thu, 10 Oct 2013 07:43:20 -0700

somewhat

---

From: joel jaeggli <[email-masked]>
Date: Thu, 10 Oct 2013 08:19:34 -0700

> One application for this is where one partly owns both AS, for example

agree I have a few dozen ASNs employeed in my environment ;)

> but that should not preclude the work.

yes.