Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Mar 2012 14:11:54 -0400

Alright, I'll tackle that tomorrow morning.

-chris
(cochair)

On Fri, Dec 9, 2011 at 9:03 AM, Sriram, Kotikalapudi
<[email-masked]> wrote:
> Sandy,
> Chris,
>
> The WGLC on this doc ended 09/22/2011.
> We (the authors) submitted a substantially revised version on October 31, 2011,
> taking into careful consideration all comments that were received during the WGLC.
> Please see Warren's note (attached below).
> The authors feel that this document is now ripe and ready for wrapping up the WGLC.
> Thanks.
>
> Sriram
> ________________________________________
> From: Warren Kumari [[email-masked]]
> Sent: Thursday, November 03, 2011 1:06 PM
> To: Sriram, Kotikalapudi
> Cc: Warren Kumari; Randy Bush; [email-masked] list
> Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
>
> On Oct 31, 2011, at 7:56 PM, Sriram, Kotikalapudi wrote:
>
>> In this revised version, we (authors) have made changes with careful consideration
>> of all the comments (mostly of editorial nature) received from Warren and Randy.
>>
>> http://www.ietf.org/mail-archive/web/sidr/current/msg03349.html
>> http://www.ietf.org/mail-archive/web/sidr/current/msg03306.html
>> http://www.ietf.org/mail-archive/web/sidr/current/msg03305.html
>> http://www.ietf.org/mail-archive/web/sidr/current/msg03304.html
>>
>> We have also made many other edits throughout the doc to improve
>> clarity and readability.
>
>
> Thank you.
>
> I support this moving forward (which is just a formality, I supported it before as well, this all just makes it (IMO) better)..
>
> W
>
>>
>> Sriram
>> ________________________________________
>>
>>        Title           : Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties
>>        Author(s)       : Terry Manderson
>>                          Kotikalapudi Sriram
>>                          Russ White
>>        Filename        : draft-ietf-sidr-usecases-03.txt
>>        Pages           : 30
>>        Date            : 2011-10-31
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-03.txt
>>
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Brian Dickson <[email-masked]>
Date: Thu, 29 Mar 2012 15:11:08 -0400

Hang on, and notwithstanding the request for WGLC.

I think the use cases are likely to be informed by protocol design, so even
if they are baked, I'd argue that at best that would be only halfway baked.

I have a few examples that I can think of, which would necessarily depend
significantly on design choices which have been made "by default", but
which may turn out to be poor choices, or where later discoveries could
result in better choices.

I'd prefer this to be added to a "raft" of IDs, for which there is no rush
to publish until they are all completed, after which the timing would be
appropriate.

Here's an example of use-case, which depends on certain assumptions (which
may or may not be appropriate, but which are fodder for discussion):

Suppose there is an Edge-AS "E", and transit providers to "E", which would
be "X" and "Y".

Suppose "E" does not do BGPSEC (per se), but wants to have BGPSEC signing
done "for her", by "X" and "Y".

(Ignore for the moment that the _current_ designs don't support that, that
is an entirely other rat-hole for the moment.)

What "E" would want to do, is have a delegation, controlled by "E", towards
both "X" and "Y" which allow "X" and "Y" to create proxy-path-signatures
and proxy-originations, of "X E" and "Y E" respectively.

This is about origination, is related partly to BGPSEC
requirements/architecture/design/protocol, and necessarily has to do with
RP validation based on ROAs.

It would be, in theory, possible for _either_ X _or_ Y to completely
opaquely proxy for "E", but not for "E" to maintain control, nor to have
both X _and_ Y proxy, transparently or opaquely.

I don't think we need to fully address this use case just yet, but rather
it is an example of something that justifies putting the WGLC on hold, or
at least holding it at immediate-post-WGLC state, for further revision
pending other work on the protocol.

Having decisions based on prior work, rather than informed experience in
deployment, and subsequently locked in, is an example of "bad design"
methodology.

And publishing something IMHO prematurely, locks the WG into that RFC,
making revising it much harder, than if it were still in-WG and
not-yet-published.

(It may turn out to eventually be unchanged, but we should not presuppose
that. This applies not just to this doc, but pretty much all the docs. We
can make progress on them and "freeze" them without publishing them
piece-meal, and I think the WG output would be much better for doing so.)

Brian

On Thu, Mar 29, 2012 at 2:11 PM, Christopher Morrow <[email-masked]
> wrote:

> > I support this moving forward (which is just a formality, I supported it
> before as well, this all just makes it (IMO) better)..
> >
> > W
> >
> >>
> >> Sriram

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 29 Mar 2012 19:21:05 -0400

> I think the use cases are likely to be informed by protocol design, so even

s/informed by protocol design/altered if the protocol design changes/

I'm not sure if the protocol design's going to change the use-cases...
you're still going to want to secure a route. (not an important point)

> I have a few examples that I can think of, which would necessarily depend
<snip>
> to publish until they are all completed, after which the timing would be

I'm not against this, though we've got a document hanging out post
WGLC (perhaps it ought to be re-reviewed if the changes were
significant... anyway) and we'll have to keep kicking it each 5.5
months to stay 'alive'. (again, not super important, and see below as
well)

> is an entirely other rat-hole for the moment.)

hrm, in:

  <http://tools.ietf.org/id/draft-ietf-sidr-bgpsec-ops-04.txt>

section-6 there's discussion of 'only sign your one prefix, do nothing
else complex' which fits the model, albeit requiring the end site to
run some small number of commands on their device. If they wanted to
hand their private key materials to the upstreams they could do the
signing, but that seems icky (to me).

I don't know that, if implications are understood by the end site and
configurations available for use on their side, end-sites would want
to hand over control of their IP assets in this way. Running the
signing on their side should be simple enough, and low/no-cost.

> making revising it much harder, than if it were still in-WG and

I think the authors said something like: "send text" where you think
it is fit to be inserted... If other folks want to delay/re-review
they need to speak up. Consensus so far was that the document was
ready to move along.

-chris

---

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 30 Mar 2012 08:21:46 +0000

Brian, Chris.

The usecases draft was intended to describe origin validation use cases.

Route leaks (and other path validation issues) might need their own usecases draft.

But I don't think we should add those cases to this draft.

--Sandy

________________________________________
From: [email-masked] [[email-masked]] on behalf of Christopher Morrow [[email-masked]]
Sent: Thursday, March 29, 2012 7:21 PM
To: Brian Dickson
Cc: Sriram, Kotikalapudi; Chris Morrow; Murphy, Sandra; Murphy, Sandra; [email-masked] list
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt

<snip>

hrm, in:

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 30 Mar 2012 05:45:04 -0400

> But I don't think we should add those cases to this draft.

fair enough. (it seems to me)

---

From: Brian Dickson <[email-masked]>
Date: Fri, 30 Mar 2012 08:55:39 -0400

Sandy,

The use case example I included, is an origin validation use case.

The problem is the inability to have "origination" (signed injection into
BGPSEC) done by proxy, at all or especially by more than one party.

The particular situation leading to the need for this, would be a stub AS
whose router vendor does not support BGPSEC, or whose router hardware or
code base is not included in BGPSEC support by their router vendor.

(Doing a forklift upgrade to do BGPSEC is generally seen as #FAIL by
operators.)

This is likely to be a fairly common situation _among stub AS_ and, given
the current requirement for origin injection for BGPSEC, addressing this
_may_ impact the use cases document, for _origin validation_.

I'm just saying...

Brian

On Fri, Mar 30, 2012 at 4:21 AM, Murphy, Sandra <[email-masked]>wrote:

> From: [email-masked] [[email-masked]] on
> behalf of Christopher Morrow [[email-masked]]

---

From: "Murphy, Sandra" <[email-masked]>
Date: Sat, 31 Mar 2012 04:12:10 +0000

speaking as regular ol' member

I'm not really sure what you are talking about here.

You speak of bgpsec and signing - that is not origin validation, that is path validation.

Origin validation is strictly and only judging whether the origin has the authority to originate announcements of the prefix.  Origin validation does not ensure that the authorized AS is actually making the announcement.

It is bgpsec path validation that ensures that the announcement is currently and authentically being announced by the AS.  That's the "signed injection" you mention.

--Sandy

________________________________
From: Brian Dickson [[email-masked]]
Sent: Friday, March 30, 2012 8:55 AM
To: Murphy, Sandra
Cc: Christopher Morrow; Sriram, Kotikalapudi; Chris Morrow; [email-masked] list
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt

Sandy,

The problem is the inability to have "origination" (signed injection into BGPSEC) done by proxy, at all or especially by more than one party.

The particular situation leading to the need for this, would be a stub AS whose router vendor does not support BGPSEC, or whose router hardware or code base is not included in BGPSEC support by their router vendor.

(Doing a forklift upgrade to do BGPSEC is generally seen as #FAIL by operators.)

This is likely to be a fairly common situation _among stub AS_ and, given the current requirement for origin injection for BGPSEC, addressing this _may_ impact the use cases document, for _origin validation_.

I'm just saying...

Brian

On Fri, Mar 30, 2012 at 4:21 AM, Murphy, Sandra <[email-masked]<mailto:[email-masked]>> wrote:
Brian, Chris.

--Sandy

________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Christopher Morrow [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 29, 2012 7:21 PM
To: Brian Dickson
Cc: Sriram, Kotikalapudi; Chris Morrow; Murphy, Sandra; Murphy, Sandra; [email-masked]<mailto:[email-masked]> list
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt

<snip>

hrm, in:

-chris

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sat, 31 Mar 2012 16:31:12 -0400

Brian,

There is a clear distinction between “prefix-origin validation” (based on ROA information) 
and "origination (signed injection into BGPSEC)" in the SIDR working group's usage of these terms. 
You seem to be attempting to use these two terms with the same connotation. 
Your comments clearly pertain to path signing. You seem to be especially concerned about 
path signing by a stub origin AS or by a proxy AS (e.g., the stub AS's upstream transit provider). 
Draft-ietf-sidr-usecases I-D documents use cases relating only to “prefix-origin validation”.
A use-cases document for the path signing would be a separate document; 
as far as I know no one is working on it at the moment. 
So your comments seem misplaced, i.e., they appear not relevant to draft-ietf-sidr-usecases. 
Please also see my response in my other post that follows this post, but with the subject:
stub AS and proxy signing. 
Thank you.

Sriram      

>
> To: Brian Dickson <brian.peter.dickson at gmail.com>
> From: "Murphy, Sandra" <Sandra.Murphy at sparta.com>
> Date: Sat, 31 Mar 2012 04:12:10 +0000
>
> Origin validation is strictly and only judging whether the origin has
> the authority to originate announcements of the prefix.  Origin
> validation does not ensure that the authorized AS is actually making
> the announcement.
>
> It is bgpsec path validation that ensures that the announcement is
> currently and authentically being announced by the AS.  That's the
> "signed injection" you mention.
>
> --Sandy
>
> From: Brian Dickson [brian.peter.dickson at gmail.com]
> Cc: Christopher Morrow; Sriram, Kotikalapudi; Chris Morrow; sidr at
> ietf.org list
> The problem is the inability to have "origination" (signed injection
> into BGPSEC) done by proxy, at all or especially by more than one
> party.
>
> The particular situation leading to the need for this, would be a stub
> AS whose router vendor does not support BGPSEC, or whose router
> hardware or code base is not included in BGPSEC support by their
> router vendor.
>
> This is likely to be a fairly common situation _among stub AS_ and,
> given the current requirement for origin injection for BGPSEC,
> addressing this _may_ impact the use cases document, for _origin
> validation_.
>
> I'm just saying...
>
> Brian
>
> On Fri, Mar 30, 2012 at 4:21 AM, Murphy, Sandra <Sandra.Murphy at
> sparta.com> wrote:
> Brian, Chris.
>
> From: christopher.morrow at gmail.com [christopher.morrow at
> gmail.com] on behalf of Christopher Morrow [morrowc.lists at
> gmail.com]
> <brian.peter.dickson at gmail.com> wrote:
>

---

From: Brian Dickson <[email-masked]>
Date: Sat, 31 Mar 2012 17:09:25 -0400

Sriram, and Sandy,

Yes, and no, on the question of whether this is an origin-validation or
path-validation issue.

Actually, that is where the problem originates, if you forgive the double
meaning.

Both the protocol spec (for bgpsec) and the use-cases, and all of the
particulars of the RPKI design,
require all the pertinent details to be aligned.

If you consider what the current draft of the protocol spec says,
specifically on sections 4.1 and 5.1,
about originating, and validating origination, it specifically references
ROA from RPKI.

What this means is, that any change to where bgpsec "begins" signatures,
will necessarily require
revisiting ROA components or structures or whatever, which then require
revisiting anything that
refers to those ROAs, which includes pretty much everything on the
origin-validation front.

It is all fine and well to do origin-validation based on BGP origination,
but since the current design
of bgpsec is anchored to (vanilla, non-sec) BGP origination as well, this
means identifying affected
elements when challenging the bgpsec design.

And, what I'm suggesting is, that restricting bgpsec deployment to only
origin AS operators who deploy
bgpsec (i.e. excluding proxy injection into bgpsec from non-bgpsec
origins), is not something the operator
community is likely to accept with open arms.

There are too many edge ASNs today, using too many vendors' equipment with
too many varieties
of equipment within vendors, and too varied code base, to believe rapid
uptake or critical mass is
feasible in the timeline the WG participants might like to believe.

And I don't believe the opinions of participants in the WG is sufficient to
say yay or nay to the current assumption.

So, it is only a consequence of other decisions, that use-cases is touched
on. However, that it is, is provable
by simple classic logic.

A->B and B->C, when combined with !C, means !B, means !A.
Here, C is edge-ASNs doing BGPSEC, B is ROAs exclusively tied to BGP origin
ASNs, and A is use-cases as currently enumerated.

The document, other than the corner cases such as this (proxy origination
on the bgpsec side), is fine.

Brian