Subject: [sidr] Kathleen Moriarty's Discuss on draft-ietf-sidr-as-migration-05: (with DISCUSS)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 02 May 2016 10:04:17 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-sidr-as-migration-05: Discuss

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.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm wondering a few things that I think are important to discuss.  If
this is all fine, I may have more comments as I think I'll need to dig
into the BGPsec draft first and then this one again.

1.  Why is this document preceding the BGP spec?  Shouldn't this be part
of the BGPSec protocol document?  If BGPSec isn't getting deployed
because of the AS path migration problem and this gets us a little
further, but not quite as secure, maybe that's a trade off we need to
accept.  But this document coming through first is a little concerning
even though the protocol spec is a normative reference. 

2.  The introduction makes this sound rather innocuous, but the security
considerations section is more explicit that this is a work around BGPSec
and isn't quite as secure.  I'd like to see some text explaining this
better in the introduction, more similar to what's in the first paragraph
of the security considerations section.

Thank you

---

From: joel jaeggli <[email-masked]>
Date: Mon, 2 May 2016 10:25:18 -0700

> https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/

I have a lot of trouble imagining that this one could usefully be
published without the other.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 2 May 2016 19:31:59 +0000

WG] This is largely a timing problem. The protocol draft was written
first, but after this issue was identified, AS-migration was written, and
both drafts were revised and reviewed in parallel.
The WG discussed integrating AS-migration into the protocol spec, and
decided to keep it separate. At the time, this was due to several
dependencies and assumptions:
First, the WG consensus between SIDR, GROW, and RTGWG was that BGPSec
definitely needed to allow for AS-Migration, but before BGPSec could be
expected to support AS-Migration, those tools needed to be documented as a
formal part of the BGP protocol (in RTGWG), rather than just being de
facto standard on account of their being implemented by all major router
vendors and widely used by ISPs. That resulted in RFC 7705 (aka
idr-as-migration), also written largely in parallel with sidr-as-migration
(in fact they started as one document and were split).
Second, the BGPSec protocol document was thought to be much closer to
completion and publishing than either of these documents, and was expected
to be completed well prior to sidr-as-migration such that it didn't make
much sense to delay the protocol doc to integrate them.
In the meantime, the protocol document underwent additional reviews that
uncovered issues requiring more significant revision and delayed its
progress such that the as-migration document is now ready first. The
protocol document has had edits to ensure proper integration between the
two documents where appropriate (adding clarity via references and
language to ensure no conflict in what is being directed in each standard).
Last, part of the rationale for keeping them separate is that while the WG
strongly recommends that both parts be implemented, BGPSec does not
strictly require the additional support for AS-migration (I.e.
Implementing the functionality defined in BGPSec protocol document is a
MUST, AS-migration is a SHOULD), and thus having the documents be separate
makes a clear distinction between basic protocol function and add-on
features.

>of the security considerations section.

WG] The intent was not to imply that BGPSec with AS-Migration support is
fundamentally less secure than BGPSec without it, so if that's what we're
conveying between the two sections, I'd appreciate additional guidance on
what specifically is giving you that impression. It's not really a
work-around BGPSec as much as it's observing that the BGPSec protocol as
written would break this common method for AS-Migration, and this document
addresses that gap by ensuring that it can be done within the security
framework provided by BGPSec.

Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 3 May 2016 11:30:59 +0100

Hi Wes,

(FWIW, I agree with Kathleen's DISCUSS on this but one question
below before I post my own ballot...)

> makes a clear distinction between basic protocol function and add-on

This is only a timing problem if bgpsec doesn't change in some
incompatible manner. If such a change happens then this is more
than a timing issue.

What'd be bad about just holding this in the WG until bgpsec is
ready? Since there's a normative reference anyway getting the
IESG to approve both at once seems like it'd be better.

Cheers,
S.

---

From: "George, Wes" <[email-masked]>
Date: Tue, 3 May 2016 14:02:58 +0000

>IESG to approve both at once seems like it'd be better.

WG] Well, I don't think the BGPSec protocol draft is really far enough
behind that holding this one would make much difference in the outcome. My
co-author (and WG Chair) replied in another thread that the BGPSec doc is
past WGLC and waiting for chair publication request. The primary thing
outstanding is a discussion between the Routing ADs and WG as to whether
it will be experimental status or PS. If you have concerns, both drafts
are sufficiently complete that you could review both now, but I don't
expect major chances of the type you express concern about at this late
stage.
As primary author, I can say that I'd really like this to be off my plate
and in the RFC editor's queue, because given current job/merger
uncertainty, I can't be certain what my involvement with IETF will be in
the coming months. Completing approval on this one while it's in queue
also seems a better use of IESG cycles rather than re-cycling the draft
such that it has to be reviewed and discussed by IESG a second time, but I
defer to the WG and IESG as to how to proceed here.

Thanks,

Wes George

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 3 May 2016 15:36:53 +0100

Hiya,

On 03/05/16 15:02, George, Wes wrote:
> Completing approval on this one while it's in queue
> also seems a better use of IESG cycles

It's a minor point but evaluating this one really calls
for having reviewed bgpsec as well so I think doing this
one 1st will be a slightly less good use of IESG cycles.

But, like I said, that's a minor point (assuming that
bgpsec is in a good enough state - if it's not then I don't
see how the IESG could approve this).

S.