Re: [sidr] Opsdir last call review of draft-ietf-sidrops-rtr-keying-02

[Christopher Morrow]

BCP seems like a fine answer here, I'm not remembering why we would have
swapped to ST from BCP.

On Wed, Dec 26, 2018 at 11:12 AM Warren Kumari  wrote:

> [ + Sandy, Alvaro ]
>
> On Wed, Dec 26, 2018 at 9:51 AM Scott Bradner  wrote:
>
>> that use of a MUST is commendable but its not exactly an interoperability
>> issue
>>
>> to me “must” works in this case (and the other cases in this document)
>>
>> but, that said, 2119 has been misused for kinda a long time so its not a
>> new sin
>>
>>
> This document has a long history -- it was originally a product of the
> SIDR Working Group (as draft-ietf-sidr-rtr-keying), and only moved over to
> SIDROPS recently, when SIDR closed down (
> https://datatracker.ietf.org/wg/sidr/about/).
>
> The document was originally a BCP (
> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/09/), but was
> changed to Standards Track in -10 (
> https://www.ietf.org/archive/id/draft-ietf-sidr-rtr-keying-10.txt).
>
>
> I have gone back through the agenda and minutes for IETF 92 (
> https://datatracker.ietf.org/doc/agenda-92-sidr/), IETF 93 (
> https://datatracker.ietf.org/doc/agenda-93-sidr/) and IETF 94 (
> https://datatracker.ietf.org/doc/agenda-94-sidr/).
> I also went back and watched the video recordings from IETF 94:
> https://youtu.be/fElkBi4UMEA?t=2397 and wasn't able to find any
> discussion of why the change was made, but I *was* able to find some
> changes made between -09 and -10 which seem to be the outcome of those
> discussions.
>
> Authors / SIDROPS [0] & SIDR / chairs -  can y'all remember why the track
> change was made?
>
> Whatever the case, the IETF LC was done as Standards Track (a higher
> level), and so it could always be "downgraded" to BCP / informational
> during IESG Eval.
> I personally think it "feels" like BCP, but I don't have full history /
> inherited the document and don't want to be arbitrarily making changes.
>
>
> W
> [0]: SIDROPS and SIDR participant overlap is almost 100%.
>
>
>
>
>> Scott
>>
>> > On Dec 26, 2018, at 9:25 AM, Randy Bush  wrote:
>> >
>> > mornin’ scott,
>> >
>> >> it is hard to see why it should be standards track or why it should
>> >> be using RFC 2119 type terminology.
>> >
>> > these are two separate issues.
>> >
>> > alvaro and the chairs can adjudicate what flavor of ice cream it should
>> > be.  it my memory says it was a wg decision.  i really do not care.
>> >
>> > as to 2119 language, i kinda feel it should remain.  it is used
>> > sparingly. but is crucial when used.  e.g.
>> >
>> >  all private keys MUST be protected when at rest in a secure
>> >  fashion.
>> >
>> > i suspect we would want to keep that strongly prescriptive; but it is
>> > not a hill on which i am interested in dying.
>> >
>> > randy
>>
>>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>---maf
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-16.txt

[Christopher Morrow]

Howdy sidrops folks, this document was left hanging in SIDR, it probably
was better fit to sidr-ops, so let's get Sean to re-spin a re-named
document, auto-adopt that and chat up any changes/etc between now and
'meeting time' ?

Ideally we can turn around after the meeting breaks and WGLC this document
in SIDROPS, unless changes are requested (of course!) :)

thanks!
-chris

On Thu, Aug 30, 2018 at 11:30 AM Sean Turner  wrote:

> This version I believes addresses the two outstanding issues Sandy raised
> during her review.
>
> spt
>
> > On Aug 30, 2018, at 14:28, internet-dra...@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Secure Inter-Domain Routing WG of the
> IETF.
> >
> >Title   : Router Keying for BGPsec
> >Authors : Randy Bush
> >  Sean Turner
> >  Keyur Patel
> >   Filename: draft-ietf-sidr-rtr-keying-16.txt
> >   Pages   : 18
> >   Date: 2018-08-30
> >
> > Abstract:
> >   BGPsec-speaking routers are provisioned with private keys in order to
> >   sign BGPsec announcements.  The corresponding public keys are
> >   published in the global Resource Public Key Infrastructure, enabling
> >   verification of BGPsec messages.  This document describes two methods
> >   of generating the public-private key-pairs: router-driven and
> >   operator-driven.
> >
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-16
> > https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-16
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-16
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > ___
> > I-D-Announce mailing list
> > i-d-annou...@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] [Editorial Errata Reported] RFC6487 (5190)

[Christopher Morrow]

spare > seems spare...

On Tue, Nov 28, 2017 at 9:19 AM, RFC Errata System <
rfc-edi...@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC6487,
> "A Profile for X.509 PKIX Resource Certificates".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5190
>
> --
> Type: Editorial
> Reported by: Nikolai Malykh 
>
> Section: 8
>
> Original Text
> -
>  3) A randomly generated ASCII HEX encoded string of length 20
> or greater:
> example: cn="0f8fcc28e3be4869bc5f8fa114db05e1">
> (A string of 20 ASCII HEX digits would have 80-bits of
> entropy)
>
>
> Corrected Text
> --
>  3) A randomly generated ASCII HEX encoded string of length 20
> or greater:
> example: cn="0f8fcc28e3be4869bc5f8fa114db05e1"
> (A string of 20 ASCII HEX digits would have 80-bits of
> entropy)
>
>
> Notes
> -
> Typo
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC6487 (draft-ietf-sidr-res-certs-22)
> --
> Title   : A Profile for X.509 PKIX Resource Certificates
> Publication Date: February 2012
> Author(s)   : G. Huston, G. Michaelson, R. Loomans
> Category: PROPOSED STANDARD
> Source  : Secure Inter-Domain Routing
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Christopher Morrow]

On Tue, Jan 3, 2017 at 6:31 PM, Randy Bush  wrote:

> >> ok, i have had coffee.
> >>
> >> as a bif gedanken experiment, posit a global registry where r0 can say
> >> "i can speak bgpsec."  i am a distant r1 and receive an unsigned path
> >> with r0 in it.
> >>   o did someone before r0 on the path not speak bgpsec, so the path was
> >> never signed?
> >>   o did someone between us not speak bgpsec, so the path was stripped?
> >>   o was there a monkey in the middle?
> >>
> >> i think we did discuss this problem space, and decided that, as long as
> >> we allow islands of partial deployment, and therefore path stripping,
> >> the monkey is on our back.  we might have been wrong in this; but even
> >> with coffee i do not see a way out.
> >>
> >> and i do not think the idea of partial path signing, r0 signing a
> >> received unsigned path, would have helped a lot.
> >>
> >> it is not clear to me that this is a space where the ops doc can help
> >> much.  i am open to ideas.
> >
> > I'm currently not using bgpsec (or rpki for that matter).  BUT, if there
> > was no path to go back, I would never ever use it.  Destroying my ASN
> > because I wasn't ready to migrate is a straight-up No Go(tm).
> >
> > Mistakes will be made.  Rolling back will happen.  Preventing rolling
> > back will kill the baby and will guarentee this will never be rolled
> > out.
>
> what do you mean by "no path to go back" and "rolling back?"
>
>
perhaps to paraphrase peter's question/comment: He's worried that the
proposed standard may leave a user of the technology in a position where
'old bgp' is not functioning for him.

I believe we ran over this horse several times in the WG and other places,
basically to provide a path from 'today' to 'tomorrow' the ability to
co-exist is required. On day-0 no bgpsec exists, on day-1 you (peter) turn
up your first bgpsec peer  pop champagne and rejoice... On day-2 you turn
up 200 more... then on day-10 you realize things are not working so you
disable bgpsec via some knob on your vendors' devices...

All along both 'old bgp' and 'new bgpsec bgp' are working alongside each
other. Randy's correct that the protocol / etc specs cover this sort of
thing... fairly well.

Because 'there are no flag days' on the intertubes, we have to plan for
co-existence... Just like ipv6 did... wait, I mean dnssec. ;)

-chris
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Thu, Dec 1, 2016 at 1:51 AM, Declan Ma <m...@zdns.cn> wrote:

> Chris,
>
> I would like to take this thread to request for comments on how to move on
> SLURM.
>
> During the Seoul meeting, Tim suggested moving it to SIDROPS since SIDR is
> being closed.
>
> Yet I had the impression that the AD hopes keeping the list/structure
> going until current work items are done.
>
> Considering the only issue facing SLURM is the file format that Tim and
> Rudiger mentioned in the MIC, IMHO, if this WG won’t plan to move SLURM to
> SIDROPS, WGLC is desirable to bring about inputs and comments to conclude
> this work.
>
>
if we're just haggling on format... then let's try to finish here?
How about we give it until ~monday for comments here, then start WGLC if no
comments/movement?


>
> Di
>
>
> > 在 2016年12月1日，02:33，Christopher Morrow <morrowc.li...@gmail.com> 写道：
> >
> > And again, restarting... post meeting and post travel refocusing :)
> >
> > On Wed, Oct 26, 2016 at 11:35 AM, Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
> > Restarting this thread, with some updates :)
> >
> > Preparing for Seoul in a few weeks time, with the intent that we do not
> meet face-to-face in Chicago, have all current 'protocol' related docs to
> the IESG/done and meet instead in sidr-ops if there are agenda items at
> that time :)
> >
> > Currently we have the following in IESG/pub-request status (13
> documents):
> > draft-ietf-sidr-adverse-actions
> > draft-ietf-sidr-as-migration
> > draft-ietf-sidr-bgpsec-algs
> > draft-ietf-sidr-bgpsec-ops
> > draft-ietf-sidr-bgpsec-overview
> > draft-ietf-sidr-bgpsec-pki-profiles
> > draft-ietf-sidr-bgpsec-protocol
> > draft-ietf-sidr-delta-protocol (10/26 sent forward)
> >
> > draft-ietf-sidr-origin-validation-signaling
> > draft-ietf-sidr-publication
> > draft-ietf-sidr-rpki-oob-setup
> > draft-ietf-sidr-rpki-rtr-rfc6810-bis
> >
> >
> > I had thought I sent validation-reconsidered forward for processing, I'm
> doing that today:
> > draft-ietf-sidr-rpki-validation-reconsidered
> >
> >  Currently still active documents (6 documents):
> >
> > draft-ietf-sidr-bgpsec-rollover
> > draft-ietf-sidr-lta-use-cases
> > draft-ietf-sidr-route-server-rpki-light
> > draft-ietf-sidr-rpki-tree-validation
> > draft-ietf-sidr-rtr-keying
> > draft-ietf-sidr-slurm
> >
> > (this reflects the changes since the last email, included below)
> >
> > I believe we're still planning to move (and have agreement from authors):
> >  draft-ietf-sidr-bgpsec-rollover
> >  draft-ietf-sidr-lta-use-cases
> >  draft-ietf-sidr-route-server-rpki-light
> >  draft-ietf-sidr-rtr-keying
> >
> > draft-ietf-sidr-rpki-tree-validation
> >
> > which leaves to be dealt with by Chicago 2 documents:
> > draft-ietf-sidr-slurm
> >
> > I think this is good, I believe (and of course I should be corrected if
> wrong)
> >   slurm - more work inbound and discussion planned in Seoul
> >   tree-validation - I thought moved to sidr-ops, but don't have docs to
> back that up.
> >
> >
> > I still think this is good, I will be sending a request to the OPS-AD
> folk today to move:
> >  draft-ietf-sidr-bgpsec-rollover
> >  draft-ietf-sidr-lta-use-cases
> >  draft-ietf-sidr-route-server-rpki-light
> >  draft-ietf-sidr-rtr-keying
> >  draft-ietf-sidr-rpki-tree-validation
> >
> > to sidr-ops... If there are corrections/additions please send them along
> :)
> >
> > -chris
> >
> > -chris
> >
> > On Fri, Sep 2, 2016 at 4:56 PM, Chris Morrow <morr...@ops-netman.net>
> wrote:
> >
> > Howdy SIDR peeps,
> > (+bonus ops ad)
> >
> > Following on the Berlin meeting we were trying to accomplish two
> > things:
> >
> >   1) get all documents related to sidr protocols into wglc and then
> >   publication
> >
> >   2) get all documents which are more operationally focused moved
> >   along to an ops group (sidr-ops or something akin to that)
> >
> > With that in mind there are 8 documents in the publication queue:
> >   draft-ietf-sidr-as-migration
> >   draft-ietf-sidr-bgpsec-algs
> >   draft-ietf-sidr-bgpsec-ops
> >   draft-ietf-sidr-bgpsec-overview
> >   draft-ietf-sidr-bgpsec-pki-profiles
> >   draft-ietf-sidr-bgpsec-protocol
> >   draft-ietf-sidr-origin-validation-signaling
> >   draft-ietf-sidr-rpki-rtr-rfc6810-bis
> >
> > and 11 still in progress. Of the 11 left Sandy and I think they

Re: [sidr] Current document status && directionz

[Christopher Morrow]

And again, restarting... post meeting and post travel refocusing :)

On Wed, Oct 26, 2016 at 11:35 AM, Christopher Morrow <
morrowc.li...@gmail.com> wrote:

> Restarting this thread, with some updates :)
>
> Preparing for Seoul in a few weeks time, with the intent that we do not
> meet face-to-face in Chicago, have all current 'protocol' related docs to
> the IESG/done and meet instead in sidr-ops if there are agenda items at
> that time :)
>
> Currently we have the following in IESG/pub-request status (13 documents):
> draft-ietf-sidr-adverse-actions
> draft-ietf-sidr-as-migration
> draft-ietf-sidr-bgpsec-algs
> draft-ietf-sidr-bgpsec-ops
> draft-ietf-sidr-bgpsec-overview
> draft-ietf-sidr-bgpsec-pki-profiles
> draft-ietf-sidr-bgpsec-protocol
>
draft-ietf-sidr-delta-protocol (10/26 sent forward)


> draft-ietf-sidr-origin-validation-signaling
> draft-ietf-sidr-publication
> draft-ietf-sidr-rpki-oob-setup
> draft-ietf-sidr-rpki-rtr-rfc6810-bis
>


I had thought I sent validation-reconsidered forward for processing, I'm
doing that today:

> draft-ietf-sidr-rpki-validation-reconsidered
>

 Currently still active documents (6 documents):

>

> draft-ietf-sidr-bgpsec-rollover
> draft-ietf-sidr-lta-use-cases
> draft-ietf-sidr-route-server-rpki-light
> draft-ietf-sidr-rpki-tree-validation
> draft-ietf-sidr-rtr-keying
> draft-ietf-sidr-slurm
>
> (this reflects the changes since the last email, included below)
>
> I believe we're still planning to move (and have agreement from authors):
>  draft-ietf-sidr-bgpsec-rollover
>  draft-ietf-sidr-lta-use-cases
>  draft-ietf-sidr-route-server-rpki-light
>  draft-ietf-sidr-rtr-keying
>

draft-ietf-sidr-rpki-tree-validation


> which leaves to be dealt with by Chicago 2 documents:
> draft-ietf-sidr-slurm
>
> I think this is good, I believe (and of course I should be corrected if
> wrong)
>   slurm - more work inbound and discussion planned in Seoul
>   tree-validation - I thought moved to sidr-ops, but don't have docs to
> back that up.
>
>
I still think this is good, I will be sending a request to the OPS-AD folk
today to move:
 draft-ietf-sidr-bgpsec-rollover
 draft-ietf-sidr-lta-use-cases
 draft-ietf-sidr-route-server-rpki-light
 draft-ietf-sidr-rtr-keying
 draft-ietf-sidr-rpki-tree-validation

to sidr-ops... If there are corrections/additions please send them along :)

-chris


> -chris
>
> On Fri, Sep 2, 2016 at 4:56 PM, Chris Morrow <morr...@ops-netman.net>
> wrote:
>
>>
>> Howdy SIDR peeps,
>> (+bonus ops ad)
>>
>> Following on the Berlin meeting we were trying to accomplish two
>> things:
>>
>>   1) get all documents related to sidr protocols into wglc and then
>>   publication
>>
>>   2) get all documents which are more operationally focused moved
>>   along to an ops group (sidr-ops or something akin to that)
>>
>> With that in mind there are 8 documents in the publication queue:
>>   draft-ietf-sidr-as-migration
>>   draft-ietf-sidr-bgpsec-algs
>>   draft-ietf-sidr-bgpsec-ops
>>   draft-ietf-sidr-bgpsec-overview
>>   draft-ietf-sidr-bgpsec-pki-profiles
>>   draft-ietf-sidr-bgpsec-protocol
>>   draft-ietf-sidr-origin-validation-signaling
>>   draft-ietf-sidr-rpki-rtr-rfc6810-bis
>>
>> and 11 still in progress. Of the 11 left Sandy and I think they
>> roughly break down like:
>>
>> Documents which should move to the ops group:
>>   draft-ietf-sidr-bgpsec-rollover
>>   draft-ietf-sidr-lta-use-cases
>>   draft-ietf-sidr-route-server-rpki-light - authors notified/queried
>> about this
>>   draft-ietf-sidr-rtr-keying
>>
>> documents which should finish out in sidr:
>>   draft-ietf-sidr-delta-protocol
>>   draft-ietf-sidr-publication
>>   draft-ietf-sidr-rpki-oob-setup - pub request in flight
>>   draft-ietf-sidr-rpki-tree-validation
>>   draft-ietf-sidr-rpki-validation-reconsidered
>>   draft-ietf-sidr-slurm - authors recently updated
>>   draft-ietf-sidr-adverse-actions - wglc imminent
>>
>> I think if there's no meaningful discussion on change for these
>> between now and 9/16/2016 (Sept 16th) we will assume this list is
>> correct. For documents in the 'move' list, if progress to publication
>> happens 'good!'. For all documents in the 'stays' list:
>>   1) we aim to have wglc by Seoul
>>   2) publication requests started on as many as possible
>>
>> We plan to meet in Seoul, but not in Chicago (Mar 2017) where we
>> expect the ops group to exist and meet. We can progress documents in
>> SIDR after Seoul, but the WG should close out shortly after the new
>> year. (or that's the goal).
>>
>> Thoughts?
>> -chris
>>
>> ___
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>>
>
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Agenda Upload

[Christopher Morrow]

FYI: Draft Agenda updated, happy to accept changes still :)

On Tue, Nov 8, 2016 at 7:00 PM, Declan Ma  wrote:

> +1.
>
> Intriguing!
>
> I was considering how inter-chche works.
>
> Di
>
> > 在 2016年11月8日，13:26，Randy Bush  写道：
> >
> > i stil think we should be doing some rigorous interoperability testing,
> > inter CA, caches and routers, routers applying origin validation, ...
> >
> > yes, we should be doing this in sidrops, but we all know that it will be
> > populated by the usual suspects, barring voter suppression.  so it would
> > be nice to discuss this next week, irresptive of the air cover and hats.
> >
> > randy, already in seoul noc
> >
> > ___
> > sidr mailing list
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr
>
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Wed, Oct 26, 2016 at 11:18 PM, Randy Bush  wrote:

> > Currently we have the following in IESG/pub-request status (13
> documents):
> > draft-ietf-sidr-adverse-actions
> > draft-ietf-sidr-as-migration
> > draft-ietf-sidr-bgpsec-algs
> > draft-ietf-sidr-bgpsec-ops
> > draft-ietf-sidr-bgpsec-overview
> > draft-ietf-sidr-bgpsec-pki-profiles
> > draft-ietf-sidr-bgpsec-protocol
> > draft-ietf-sidr-origin-validation-signaling
> > draft-ietf-sidr-publication
> > draft-ietf-sidr-rpki-oob-setup
> > draft-ietf-sidr-rpki-rtr-rfc6810-bis
> > draft-ietf-sidr-delta-protocol (10/26 sent forward)
> > draft-ietf-sidr-rpki-validation-reconsidered (10/26 sent forward)
>
> an interesting view on progress of these documents is visible in
> https://datatracker.ietf.org/doc/ad/alvaro.retana/


yes, the chairs posed the question: "Err, did we sink your battleship with
too many docks?" to alvaro, he's still using his snorkel to swim out of the
trench... he'll get there  he says :)

(and basically we did our job pushing documents forward and working through
the discussions 'we' here == 'working-group' not 'me'  Thanks to the WG
folk for doing some hard work and focusing)

-chris
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

Restarting this thread, with some updates :)

Preparing for Seoul in a few weeks time, with the intent that we do not
meet face-to-face in Chicago, have all current 'protocol' related docs to
the IESG/done and meet instead in sidr-ops if there are agenda items at
that time :)

Currently we have the following in IESG/pub-request status (13 documents):
draft-ietf-sidr-adverse-actions
draft-ietf-sidr-as-migration
draft-ietf-sidr-bgpsec-algs
draft-ietf-sidr-bgpsec-ops
draft-ietf-sidr-bgpsec-overview
draft-ietf-sidr-bgpsec-pki-profiles
draft-ietf-sidr-bgpsec-protocol
draft-ietf-sidr-origin-validation-signaling
draft-ietf-sidr-publication
draft-ietf-sidr-rpki-oob-setup
draft-ietf-sidr-rpki-rtr-rfc6810-bis
draft-ietf-sidr-delta-protocol (10/26 sent forward)
draft-ietf-sidr-rpki-validation-reconsidered (10/26 sent forward)


Currently still active documents (8 documents):
draft-ietf-sidr-bgpsec-rollover
draft-ietf-sidr-lta-use-cases
draft-ietf-sidr-route-server-rpki-light
draft-ietf-sidr-rpki-tree-validation
draft-ietf-sidr-rpki-validation-reconsidered
draft-ietf-sidr-rtr-keying
draft-ietf-sidr-slurm

(this reflects the changes since the last email, included below)

I believe we're still planning to move (and have agreement from authors):
 draft-ietf-sidr-bgpsec-rollover
 draft-ietf-sidr-lta-use-cases
 draft-ietf-sidr-route-server-rpki-light
 draft-ietf-sidr-rtr-keying

which leaves to be dealt with by Chicago 2 documents:
draft-ietf-sidr-rpki-tree-validation
draft-ietf-sidr-slurm

I think this is good, I believe (and of course I should be corrected if
wrong)
  slurm - more work inbound and discussion planned in Seoul
  tree-validation - I thought moved to sidr-ops, but don't have docs to
back that up.

-chris

On Fri, Sep 2, 2016 at 4:56 PM, Chris Morrow  wrote:

>
> Howdy SIDR peeps,
> (+bonus ops ad)
>
> Following on the Berlin meeting we were trying to accomplish two
> things:
>
>   1) get all documents related to sidr protocols into wglc and then
>   publication
>
>   2) get all documents which are more operationally focused moved
>   along to an ops group (sidr-ops or something akin to that)
>
> With that in mind there are 8 documents in the publication queue:
>   draft-ietf-sidr-as-migration
>   draft-ietf-sidr-bgpsec-algs
>   draft-ietf-sidr-bgpsec-ops
>   draft-ietf-sidr-bgpsec-overview
>   draft-ietf-sidr-bgpsec-pki-profiles
>   draft-ietf-sidr-bgpsec-protocol
>   draft-ietf-sidr-origin-validation-signaling
>   draft-ietf-sidr-rpki-rtr-rfc6810-bis
>
> and 11 still in progress. Of the 11 left Sandy and I think they
> roughly break down like:
>
> Documents which should move to the ops group:
>   draft-ietf-sidr-bgpsec-rollover
>   draft-ietf-sidr-lta-use-cases
>   draft-ietf-sidr-route-server-rpki-light - authors notified/queried
> about this
>   draft-ietf-sidr-rtr-keying
>
> documents which should finish out in sidr:
>   draft-ietf-sidr-delta-protocol
>   draft-ietf-sidr-publication
>   draft-ietf-sidr-rpki-oob-setup - pub request in flight
>   draft-ietf-sidr-rpki-tree-validation
>   draft-ietf-sidr-rpki-validation-reconsidered
>   draft-ietf-sidr-slurm - authors recently updated
>   draft-ietf-sidr-adverse-actions - wglc imminent
>
> I think if there's no meaningful discussion on change for these
> between now and 9/16/2016 (Sept 16th) we will assume this list is
> correct. For documents in the 'move' list, if progress to publication
> happens 'good!'. For all documents in the 'stays' list:
>   1) we aim to have wglc by Seoul
>   2) publication requests started on as many as possible
>
> We plan to meet in Seoul, but not in Chicago (Mar 2017) where we
> expect the ops group to exist and meet. We can progress documents in
> SIDR after Seoul, but the WG should close out shortly after the new
> year. (or that's the goal).
>
> Thoughts?
> -chris
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC - draft-ietf-sidr-rpki-validation-reconsidered - ends 10/25/2016

[Christopher Morrow]

I'll prepare the shepherd doc and await an ack/nack to this mail before
pushing forward to IESG.

On Wed, Oct 26, 2016 at 11:32 AM, Tim Bruijnzeels  wrote:

> Hi Sean, Tom, Russ, and all,
>
> Sorry for bringing this up late. Technically past 25 October, and yes I
> would like to see this go through as you might expect from an author...
>
> That said, can someone with good ASN.1-fu please have look at the changes
> w.r.t. ASN.1 structure and OIDs? I tried to include all your comments
> properly - but I would feel safer if one of you could confirm.
>
> Thanks
> Tim
>
>
> > On 26 Oct 2016, at 05:13, Sriram, Kotikalapudi (Fed) <
> kotikalapudi.sri...@nist.gov> wrote:
> >
> > I read the draft once again. I support publication.
> >
> > Found a minor typo in the last paragraph on p.15 (can be dealt with
> during RFC editor review process):
> > s/the loss of on IP address prefix from the VRS-IP/the loss of one IP
> address prefix from the VRS-IP/
> >
> > Sriram
> >
> > 
> > From: sidr  on behalf of Chris Morrow <
> morr...@ops-netman.net>
> > Sent: Tuesday, October 11, 2016 10:08 AM
> > To: sidr@ietf.org; sidr-cha...@ietf.org; sidr-...@ietf.org
> > Subject: [sidr] WGLC - draft-ietf-sidr-rpki-validation-reconsidered -
> ends  10/25/2016
> >
> > Howdy WG folks!
> > The authors of:
> >  draft-ietf-sidr-rpki-validation-reconsidered
> >
> > believe they have addressed all inflight concerns/comments, the
> > request is to WGLC this, consider it's place in the world and if
> > appropriate pass this document along to the IESG for publication.
> >
> > The abstract for this draft is:
> >  "This document proposes an update to the certificate validation
> >   procedure specified in RFC 6487 that reduces aspects of operational
> >   fragility in the management of certificates in the RPKI, while
> >   retaining essential security features."
> >
> > Let's have a read through, consider and reply with your thoughts please,
> > this WGLC is set to expire: 10/25/2016 - October 25, 2016.
> >
> > thanks for reading/replying/thinking!
> > -chris
> > co-chair-persona
> >
> > ___
> > sidr mailing list
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC - draft-ietf-sidr-rpki-validation-reconsidered - ends 10/25/2016

[Christopher Morrow]

howdy! it's past 10/25, so... I think despite seeing only 2 folk reply I
think this document should move forward, so I'll send up a pub-request
shortly.

On Tue, Oct 25, 2016 at 11:13 PM, Sriram, Kotikalapudi (Fed) <
kotikalapudi.sri...@nist.gov> wrote:

> I read the draft once again. I support publication.
>
> Found a minor typo in the last paragraph on p.15 (can be dealt with during
> RFC editor review process):
> s/the loss of on IP address prefix from the VRS-IP/the loss of one IP
> address prefix from the VRS-IP/
>
> Sriram
>
> 
> From: sidr  on behalf of Chris Morrow <
> morr...@ops-netman.net>
> Sent: Tuesday, October 11, 2016 10:08 AM
> To: sidr@ietf.org; sidr-cha...@ietf.org; sidr-...@ietf.org
> Subject: [sidr] WGLC - draft-ietf-sidr-rpki-validation-reconsidered -
> ends  10/25/2016
>
> Howdy WG folks!
> The authors of:
>   draft-ietf-sidr-rpki-validation-reconsidered
>
> believe they have addressed all inflight concerns/comments, the
> request is to WGLC this, consider it's place in the world and if
> appropriate pass this document along to the IESG for publication.
>
> The abstract for this draft is:
>   "This document proposes an update to the certificate validation
>procedure specified in RFC 6487 that reduces aspects of operational
>fragility in the management of certificates in the RPKI, while
>retaining essential security features."
>
> Let's have a read through, consider and reply with your thoughts please,
> this WGLC is set to expire: 10/25/2016 - October 25, 2016.
>
> thanks for reading/replying/thinking!
> -chris
> co-chair-persona
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC - draft-ietf-sidr-delta-protocol - 10/25/2016

[Christopher Morrow]

Thanks for reading (everyone) and commenting (many folks)

this is being sent forward to the IESG now.

On Fri, Oct 21, 2016 at 12:19 PM, Sean Turner <s...@sn3rd.com> wrote:

> This whole concept is analogous to existing DAP/LDAP mechanism and the
> “delta” concept in CRLs.  Considering this protocol is run over https it
> seems like a step in the right direction away from unsecured rsync.  So the
> idea seems sensible and after re-reading the draft I think we are a go for
> launch [0].
>
> spt
>
> [0] https://www.youtube.com/watch?v=zVf-rehP4b8
>
> > On Oct 20, 2016, at 10:19, Christopher Morrow <morrowc.li...@gmail.com>
> wrote:
> >
> > Howdy!
> > 5 more days until this call expires, please read and comment... or at
> least say:
> >   "Hey! I did read this it is [awesome|horrible|acceptable|
> dumpsterfire]"
> >
> > thanks!
> > -chris
> > (feel free to cut/paste/edit the quote if it'll save you time)
> >
> > On Tue, Oct 11, 2016 at 10:15 AM, Chris Morrow <morr...@ops-netman.net>
> wrote:
> >
> > Howdy WG Folks!
> > Let's chat (email) about the subject document:
> >   draft-ietf-sidr-delta-protocol
> >
> > The authors believe they have dealt with all open items and are
> > interested in moving this document forward to IESG for
> > publication. Let's have a read/write/arithmetic time with the draft
> > and send comments/questions/suggestions/etc to the list for the
> > authors to handle or, possibly just: "yea! move this document along!"
> > if you believe it's ready for the next step in it's lifecycle.
> >
> > The WGLC should end 10/25/2016 - October 25th 2016.
> >
> > The abstract for this document is:
> >   "In the Resource Public Key Infrastructure (RPKI), certificate
> >authorities publish certificates, including end entity certificates,
> >Certificate Revocation Lists (CRL), and RPKI signed objects to
> >repositories.  Relying Parties (RP) retrieve the published
> >information from those repositories.  This document specifies a delta
> >protocol which provides relying parties with a mechanism to query a
> >repository for incremental updates, thus enabling the RP to keep its
> >state in sync with the repository."
> >
> > thanks!
> > -chris
> > co-chair-persona
> >
> > ___
> > sidr mailing list
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr
> >
> > ___
> > sidr mailing list
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr
>
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] wglc for draft-ietf-sidr-adverse-actions-00

[Christopher Morrow]

Howdy folks!
This WGLC ended up being a bit more of a long discussion than I
anticipated... I think since this WGLC there have been 2 document updates
to catch comments/concerns/etc and I think deal with them properly.

I don't see anymore chatter for this document after 9/2/2016, so I think we
should move this document forward to IESG.. I'll be sending along a pub
request today.

-chris

On Tue, Jul 19, 2016 at 10:00 AM, Stephen Kent  wrote:

> Tim,
>
>
>
> Thanks for taking the time to read and comment on the document.
>
>
>
> I will change CA certificate analysis to be section 2.1, and make the CRL
> section b 2.3, as per your request. The Manifest section will remain 2.2,
> ROAs will become 2.4, GB will become 2.5, and Router Certificates will
> remain 2.6. This will require a lot of changes to the pointers within and
> between sections, but we aim to please :-).
>
>
>
> A-5.4.1: I agree that reducing the set of  resources in a CA certificate
> may be done for legitimate reasons, even if the INR holder does not agree
> with the reduction. Nonetheless, this is an adverse action from the
> perspective of the INR holder. It’s important to note that there are cases
> when this reduction is the result of an attack against or an error by the
> parent CA. Thus I believe it is important to retain this action in the
> list.
>
>
>
>
>
> A-5.4.2: I’ll delete this action.
>
>
>
> A-5.4.5: I agree that this may be hard to distinguish from a legitimate
> key rollover, except that a key rollover would have both old and new CA
> keys present simultaneously. I’ll add a note to this effect.
>
>
>
> I disagree with your suggestion that we remove the modification,
> revocation, and injection actions for Manifests, ROAs, and Router
> Certificates. First, remember that adverse actions include errors by CAs,
> and transient attacks against CAs. In the former case the private key is
> clearly available and the CA may also control the repository. In the latter
> case note that an attacker need not need learn the private key’s value;
> he/she needs only the ability to cause an HSM to use the key. Also, an
> attacker need not control the repository to effect these actions; an RP
> might be misdirected to a different set of files via a routing system
> attack (ironic?) or a DNS attack.
>
>
>
> Recall that the goal of this document is to document, as best we can, a
> wide range of actions that are adverse, irrespective of whether we can
> prevent or detect such actions. Your message noted that RRDP may make it
> easier for RPs to detect some of these actions; I suggest you add
> references to the relevant sections of this document as further motivation
> for transitioning to RRDP.
>
>
>
> Finally, when we revised an earlier version of the document we decided to
> include every action in the same order in each section (except for GB
> records, where it would be trivial), to make it easier for a reader to see
> that we were addressing the same issues for each object.
>
> Steve
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Seoul/IETF97 Meeting Agenda Request

[Christopher Morrow]

Howdy!
So far, with 20 days to go.. there are 2 folk asking for time...
(or possibly I didn't document requests which is totally possible!)

If your name isn't Declan Ma or Joel Jaeggli and you had plans to present
something in Seoul, please contact the sidr-cha...@ietf.org for scheduling!

-chris

On Tue, Oct 11, 2016 at 12:43 AM, Chris Morrow 
wrote:

>
> howdy SIDR folk,
>
> So far there's 1 requested slot, we have possibly 2.5 hrs to discuss
> the goings-on of SIDR.
>
> Please send your agenda time requests forth-with!
>
> Please also make sure that your slides are available to the chairs by
> Monday morning (11/14/2016)... slides received after will be less
> likely to be available for use during the meeting.
>
> -chris
> co-chairing-this-event
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC - draft-ietf-sidr-delta-protocol - 10/25/2016

[Christopher Morrow]

Howdy!
5 more days until this call expires, please read and comment... or at least
say:
  "Hey! I did read this it is [awesome|horrible|acceptable|dumpsterfire]"

thanks!
-chris
(feel free to cut/paste/edit the quote if it'll save you time)

On Tue, Oct 11, 2016 at 10:15 AM, Chris Morrow 
wrote:

>
> Howdy WG Folks!
> Let's chat (email) about the subject document:
>   draft-ietf-sidr-delta-protocol
>
> The authors believe they have dealt with all open items and are
> interested in moving this document forward to IESG for
> publication. Let's have a read/write/arithmetic time with the draft
> and send comments/questions/suggestions/etc to the list for the
> authors to handle or, possibly just: "yea! move this document along!"
> if you believe it's ready for the next step in it's lifecycle.
>
> The WGLC should end 10/25/2016 - October 25th 2016.
>
> The abstract for this document is:
>   "In the Resource Public Key Infrastructure (RPKI), certificate
>authorities publish certificates, including end entity certificates,
>Certificate Revocation Lists (CRL), and RPKI signed objects to
>repositories.  Relying Parties (RP) retrieve the published
>information from those repositories.  This document specifies a delta
>protocol which provides relying parties with a mechanism to query a
>repository for incremental updates, thus enabling the RP to keep its
>state in sync with the repository."
>
> thanks!
> -chris
> co-chair-persona
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC - draft-ietf-sidr-rpki-validation-reconsidered - ends 10/25/2016

[Christopher Morrow]

Howdy WG Folks!

Have we read this document and do we have opinions on it's intended
status/direction/content/the-moon?

Thanks! (5 days til timers go off)

-chris

On Tue, Oct 11, 2016 at 10:08 AM, Chris Morrow 
wrote:

> Howdy WG folks!
> The authors of:
>   draft-ietf-sidr-rpki-validation-reconsidered
>
> believe they have addressed all inflight concerns/comments, the
> request is to WGLC this, consider it's place in the world and if
> appropriate pass this document along to the IESG for publication.
>
> The abstract for this draft is:
>   "This document proposes an update to the certificate validation
>procedure specified in RFC 6487 that reduces aspects of operational
>fragility in the management of certificates in the RPKI, while
>retaining essential security features."
>
> Let's have a read through, consider and reply with your thoughts please,
> this WGLC is set to expire: 10/25/2016 - October 25, 2016.
>
> thanks for reading/replying/thinking!
> -chris
> co-chair-persona
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC - draft-ietf-sidr-publication - ENDS: 08/18/2016 - August 18, 2016

[Christopher Morrow]

pub request sent.

On Wed, Sep 21, 2016 at 5:34 PM, Christopher Morrow <morrowc.li...@gmail.com
> wrote:

> Hey! vacation wasn't really this long, but... how about we call this
> finished, successful and I send along a pub request upstream.
>
> On Tue, Aug 23, 2016 at 10:40 AM, Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
>
>> great! once I get back to the office (monday) I'll send out the upstream
>> request.
>>
>> On Mon, Aug 22, 2016 at 8:14 AM, Oleg Muravskiy <o...@ripe.net> wrote:
>>
>>>
>>> > On 17 Aug 2016, at 01:35, Samuel Weiler <weiler+i...@watson.org>
>>> wrote:
>>> >
>>> > On Tue, 2 Aug 2016, Chris Morrow wrote:
>>> >
>>> >> Please give it a read through, and provide comments/direction in this
>>> thread.
>>> >
>>> > I am content to have this version of the doc be published on the
>>> standards track.  (Disclosure: I am the doc editor who made the most recent
>>> revisions to the doc.)
>>> >
>>> > -- Sam
>>>
>>> In the latest revision Sam addressed all my concerns, we have a working
>>> implementation, so it's good to go!
>>>
>>> Oleg
>>>
>>> ___
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr
>>>
>>
>>
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC - draft-ietf-sidr-publication - ENDS: 08/18/2016 - August 18, 2016

[Christopher Morrow]

Hey! vacation wasn't really this long, but... how about we call this
finished, successful and I send along a pub request upstream.

On Tue, Aug 23, 2016 at 10:40 AM, Christopher Morrow <
morrowc.li...@gmail.com> wrote:

> great! once I get back to the office (monday) I'll send out the upstream
> request.
>
> On Mon, Aug 22, 2016 at 8:14 AM, Oleg Muravskiy <o...@ripe.net> wrote:
>
>>
>> > On 17 Aug 2016, at 01:35, Samuel Weiler <weiler+i...@watson.org> wrote:
>> >
>> > On Tue, 2 Aug 2016, Chris Morrow wrote:
>> >
>> >> Please give it a read through, and provide comments/direction in this
>> thread.
>> >
>> > I am content to have this version of the doc be published on the
>> standards track.  (Disclosure: I am the doc editor who made the most recent
>> revisions to the doc.)
>> >
>> > -- Sam
>>
>> In the latest revision Sam addressed all my concerns, we have a working
>> implementation, so it's good to go!
>>
>> Oleg
>>
>> ___
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>>
>
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Thu, Sep 8, 2016 at 1:47 PM, David Conrad  wrote:

> Chris,
>
> sure... I think sriram may cover this in his document about the decision
> processes which lead to where we are today.
>
> I think, one way to look at the document and situation is this:
>   o community folks for each RIR asked for RPKI to be supported
>   o RIR folk put in some development $$/effort to do that
>   o no single-root came forward
>
> This is NOT accurate. ICANN, as the IANA Internet Numbering Functions
> Operator, did come forward and we were informed there was no interest from
> the RIRs for the IANA Internet Numbering Functions Operator to participate
> in testing a single root RPKI service.
>

ok, then that's distressing :( we can re-address the situation from the
rirs north through I bet?


>   o to make the RPKI work, specifically for xfers, or one way wrt
> transfers, is to fake the root at each RIR.
>   o rpki progress can still be made until single-root arrives, and then
> some re-signing and probably rough work would have to happen to move under
> the single-root.
> [...]
> apologies for not being up on the chain-of-command, but this doesn't seem
> like it's enough... we've been waiting, what are the blockers? why can't
> this action move forward? (yes, politics, let's move that to anyother list
> I  suppose)
>
> I suspect if the Internet Numbering Community would be interested in a
> single root operated by the IANA Internet Numbering Functions Operator, all
> they need do is _ask_.
>

excellent, thanks for the clarifications.
-chris


> Regards,
>
> -drc
>
> (ICANN CTO, but speaking only for myself. Really)
>
> P.S. In my previous note, I forgot to include the above disclaimer. I am
> not speaking for ICANN here.
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Thu, Sep 8, 2016 at 9:32 AM, Heasley  wrote:

>
>
> Am 08.09.2016 um 00:42 schrieb Randy Bush :
>
> >> Or maybe there's pushback that says: "Hey, I hear what you all in the
> >> rir want, but it's not cool, please please let's dive back into the
> >> politics stream and see how we get movement on what we all (probably?)
> >> want: a single root for this system."
>
> Or can the RIRs be removed from the equation? Why must we care what the
> RiRs want (fitting of many questions surrounding the RIRs)? Theyre
> essentially just agents of the IANA, its not inconceivable to replace them
> or separate duties.
>
>
sure... I think sriram may cover this in his document about the decision
processes which lead to where we are today.

I think, one way to look at the document and situation is this:
  o community folks for each RIR asked for RPKI to be supported
  o RIR folk put in some development $$/effort to do that
  o no single-root came forward
  o to make the RPKI work, specifically for xfers, or one way wrt
transfers, is to fake the root at each RIR.
  o rpki progress can still be made until single-root arrives, and then
some re-signing and probably rough work would have to happen to move under
the single-root.

sure lots of evil other things could be afoot, but I don't see evidence of
that.

again, perhaps it's worth the community folks (outside the ietf) just
saying:
  "I hear what you're saying, I like your want to keep this going forward,
but REALLY we need to sort out the issues around 'single-root' and get that
done.. the operational cost to not having a 'single-root' is just too
damned high."




> >
> > the iab did that and got a written agreement that the rirs would do so.
> > nothing more is needed other than action.


apologies for not being up on the chain-of-command, but this doesn't seem
like it's enough... we've been waiting, what are the blockers? why can't
this action move forward? (yes, politics, let's move that to anyother list
I  suppose)

-chris
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Wed, Sep 7, 2016 at 10:55 AM, Andrew de la Haye <andr...@ripe.net> wrote:

>
> On 07 Sep 2016, at 16:42, Christopher Morrow <morrowc.li...@gmail.com>
> wrote:
>
>
>
> On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein <s...@hactrn.net> wrote:
>
>> At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote:
>> >
>> > (note, I do not care for this message about politics)
>>
>> Understood, with the caveat that since it's the politics which are
>> pushing the wrong technical solution here, any technical discussion
>> will loop back to politics as soon as one asks "why?"
>>
>>
> totally agree/understand.
>
>
>> > we're here because, I think, from the top down to the RIR there isn't a
>> > hierarchy being created, right? the RIR folk are saying: "Ok, you all
>> want
>> > this thing, but upstairs hasn't created the root, so we're going to do
>> the
>> > best we can with making a root each that allows us to xfer between RIRs.
>> > This is how it's being done, so you have some docs about the mechanics
>> > involved and can build/guide from there"
>> >
>> > is that not the case? (again, I don't care about the politics)
>>
>> I'm ignoring "upstairs", because that is also political.
>>
>>
> yes, sorry I was trying to not point fingers at particular people/things :(
>
>
>> Stripped of the politics, we're having this conversation because the
>> RIRs are proposing to operate five roots instead of one, with each
>> root allowed to claim ownership over the known universe, because
>> actually coordinating with each other is Too Hard.  Or maybe it's more
>> than five, some of the RIRs have extra roots just for fun, but let's
>> take it as given for now that they'll collapse back down to five.
>>
>>
> ok
>
>
>> The problem with multiple global RPKI roots, as KC Claffy put it
>> rather neatly many years ago, is that it pushes responsibility for
>> fixing RIR coordination mistakes (which the RIRs apparently believe
>> are a serious issue, as evidenced by the draft under discussion) onto
>> the relying parties rather than forcing the RIRs to fix those issues
>> on the CA side.  This is technically broken.
>>
>>
> I think it means that since there is no single root coming 'soon', the
> RIR's are taking a step to move forward with rpki despite the 'no single
> root' existing. Ideally they would have a method to keep from being out of
> sync in their processing of requests/changes. Ideally that process would be
> outlined in the document here so we'd be able to say: "Ok, as the rpki
> lives on, how does X and Y and Z get done? what happens at X step 3 when
> Carlos decides to take a very long lunch? how does the process move along?
> what checks/balances are there?"
>
> That's the part that you're referring to as KC's comment, I think?
>
>
>> Generating a single RPKI root is not hard.  It can be done by a cron
>> job.  I ran one for years, for experimental purposes, entirely from
>> data already available to the RIRs.  The only real issue is which
>> database to believe when they disagree -- which is exactly the problem
>> the RIRs are trying to push onto the RPs with this document.
>>
>>
> I don't disagree that running a CA is 'simple'... I think though that if
> the RIRs are in a position where there won't be a single root above them
> 'for a while' (it's been ~10 yrs at this point) but they feel they need to
> move forward with something, is this direction acceptable? is it better to
> document that decision and it's gotchas than to not move forward at all? or
> to 'continue waiting for the single root' to arrive?
>
>
> Chris,
>
> fully agree, the intent is to provide unity and transparency on how the
> RIRs handle their respective trust anchors at this stage
>
>
ok, I'm glad I ddin't mis-interpret... now I'll wait on stephen/rob to pipe
back up :)
Maybe this doesn't go through a routing-area group as a document, maybe
this should really be in the ops-area group that comes out of SIDR?

Or maybe there's pushback that says: "Hey, I hear what you all in the rir
want, but it's not cool, please please let's dive back into the politics
stream and see how we get movement on what we all (probably?) want: a
single root for this system."

i'm just fishing for direction.


> Andrew
>
>
>
>
>> Which brings us back to bad technical decisions and political reasons.
>> Sorry.
>>
>
> yup.
>
>
>>
>> ___
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>>
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
>
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Wed, Sep 7, 2016 at 12:07 AM, Rob Austein <s...@hactrn.net> wrote:

> At Tue, 6 Sep 2016 22:48:07 -0400, Christopher Morrow wrote:
> >
> > (note, I do not care for this message about politics)
>
> Understood, with the caveat that since it's the politics which are
> pushing the wrong technical solution here, any technical discussion
> will loop back to politics as soon as one asks "why?"
>
>
totally agree/understand.


> > we're here because, I think, from the top down to the RIR there isn't a
> > hierarchy being created, right? the RIR folk are saying: "Ok, you all
> want
> > this thing, but upstairs hasn't created the root, so we're going to do
> the
> > best we can with making a root each that allows us to xfer between RIRs.
> > This is how it's being done, so you have some docs about the mechanics
> > involved and can build/guide from there"
> >
> > is that not the case? (again, I don't care about the politics)
>
> I'm ignoring "upstairs", because that is also political.
>
>
yes, sorry I was trying to not point fingers at particular people/things :(


> Stripped of the politics, we're having this conversation because the
> RIRs are proposing to operate five roots instead of one, with each
> root allowed to claim ownership over the known universe, because
> actually coordinating with each other is Too Hard.  Or maybe it's more
> than five, some of the RIRs have extra roots just for fun, but let's
> take it as given for now that they'll collapse back down to five.
>
>
ok


> The problem with multiple global RPKI roots, as KC Claffy put it
> rather neatly many years ago, is that it pushes responsibility for
> fixing RIR coordination mistakes (which the RIRs apparently believe
> are a serious issue, as evidenced by the draft under discussion) onto
> the relying parties rather than forcing the RIRs to fix those issues
> on the CA side.  This is technically broken.
>
>
I think it means that since there is no single root coming 'soon', the
RIR's are taking a step to move forward with rpki despite the 'no single
root' existing. Ideally they would have a method to keep from being out of
sync in their processing of requests/changes. Ideally that process would be
outlined in the document here so we'd be able to say: "Ok, as the rpki
lives on, how does X and Y and Z get done? what happens at X step 3 when
Carlos decides to take a very long lunch? how does the process move along?
what checks/balances are there?"

That's the part that you're referring to as KC's comment, I think?


> Generating a single RPKI root is not hard.  It can be done by a cron
> job.  I ran one for years, for experimental purposes, entirely from
> data already available to the RIRs.  The only real issue is which
> database to believe when they disagree -- which is exactly the problem
> the RIRs are trying to push onto the RPs with this document.
>
>
I don't disagree that running a CA is 'simple'... I think though that if
the RIRs are in a position where there won't be a single root above them
'for a while' (it's been ~10 yrs at this point) but they feel they need to
move forward with something, is this direction acceptable? is it better to
document that decision and it's gotchas than to not move forward at all? or
to 'continue waiting for the single root' to arrive?


> Which brings us back to bad technical decisions and political reasons.
> Sorry.
>

yup.


>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Current document status && directionz

[Christopher Morrow]

On Tue, Sep 6, 2016 at 6:00 PM, Rob Austein  wrote:

> I guess one question here is the purpose of publishing this document:
>
> a) If the purpose of asking the WG to publish is a hope that the WG
>will agree that this is a good idea, then I'm with Randy and Steve
>in the "hell no" camp.
>
>
(note, I do not care for this message about politics)

we're here because, I think, from the top down to the RIR there isn't a
hierarchy being created, right? the RIR folk are saying: "Ok, you all want
this thing, but upstairs hasn't created the root, so we're going to do the
best we can with making a root each that allows us to xfer between RIRs.
This is how it's being done, so you have some docs about the mechanics
involved and can build/guide from there"

is that not the case? (again, I don't care about the politics)


> b) If the purpose is to document something that the RIRs have
>unilaterally decided to do whether the IETF likes it or not, I
>guess we should thank them for documenting their intentions, and
>publish it with a big IETF / IESG disclaimer saying that it's a
>really bad idea but not something the IETF can prevent.  I suppose
>we could refuse to publish entirely in this case, but suspect that
>just makes it harder for newcomers to understand what happened.
>
> My understanding was that we were already well into case (b) territory.
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] adverse actions -01 posted

[Christopher Morrow]

On Tue, Aug 2, 2016 at 3:54 PM, Stephen Kent  wrote:

> Randy
>
>> Tim offered no suggestion for a different term, which is not helpful.
>
 the suggestion was "unwanted".

>>> I reread Tim's message; I don't interpret it as having suggested
>>> "unwanted" as an alternative.
>>>
>> that is clear.  others, such as matthias and i, did.  but this is not
>> productive.
>>
>> to be clear, i hereby suggest s/adverse/unwanted/
>>
> I will process your suggestion in the same spirit that you continue to
> ignore my comments about revising the folksy language in the LTA use cases
> document.
>
> The term "adverse" is appropriate here.
>
>
The discussion here seems to be about (though I haven't seen this word
used) connotations attached to 'adverse'.  'by the english definition'
 adverse may be correct. It may be worth using 'unwanted' though to avoid
the connotations associated with 'adverse' ?

Is the point here that occasionally a parent my ask you to eat your peas,
while you don't enjoy that thought?


> Contrary to Tim's assertion, it does not imply, ".. that for conscious
> actions by a parent CA against the will by a child CA, the parent is
> "wrong" and the child is "right."
>
> "unwanted" is a wimpy term that fails to convey the fact that the actions
> have a negative impact on the INR holder.
>
> Steve
>
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Proposal for next steps - chartering sidrops?

[Christopher Morrow]

routing-ads -> rtg-ads.

On Tue, Aug 23, 2016 at 10:32 AM, Christopher Morrow <
morrowc.li...@gmail.com> wrote:

> (fixed sidr-chairs, don't know routing-ads alias, apparently)
>
> On Tue, Aug 23, 2016 at 10:22 AM, Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
>
>> The changes from Carlos seem ok to me, and declan's points about ca/rir
>> also seem on point.
>> thanks! (for fixing the clearly network centric text!)
>>
>> On Mon, Aug 22, 2016 at 5:03 PM, joel jaeggli <joe...@bogus.com> wrote:
>>
>>> On 8/17/16 7:43 PM, Declan Ma wrote:
>>> > Joel,
>>> >
>>> > When we are talking about SIDROPS,  we are referring to that BGP
>>> speakers are resorting to RPKI relying party to get verified INR
>>> authorization information, which is created by CA and maintained by
>>> repository managers.
>>> >
>>> > IMHO, network operators are not the only RPKI role that the community
>>> is going to solicit input from.  CA operators, repository operators, RP
>>> service providers all bear significance as with SIDR Operations, in
>>> identifying issues and sharing experiences.
>>> Yeah there are a bunch of actors who are operators of elements other
>>> than networks.
>>>
>>> RIRs and CAs spring immediately to mind.
>>> > Although network operators could also be CA operators, repository
>>> operators, RP service providers, yet RIRs, CA and repository backend
>>> service providers, and third party RP don’t fall into the category of
>>> ‘network operators’.
>>> >
>>> > I would suggest the “The goals of the sidr-ops working group” be
>>> adjusted slightly, with CA operators, repository operators, RP service
>>> providers involved.
>>> yeah I think the tent should be inclusive.
>>> >
>>> > Di
>>> >
>>> >> 在 2016年8月18日，00:46，joel jaeggli <joe...@bogus.com> 写道：
>>> >>
>>> >> Folks,
>>> >>
>>> >> Some discussion prior to the recent IETF led us to ask the ask the
>>> >> question about what to do now that SIDR is close to having achieved
>>> it's
>>> >> major milestones. One possible approach we have been looking at is to
>>> >> Charter a new activity associated with the deployment and operation of
>>> >> SIDR systems within networks. Here is an initial stab at a sidrops
>>> >> charter with the milestones drawn from existing SIDR discussion.
>>> >>
>>> >> https://datatracker.ietf.org/doc/charter-ietf-sidrops/
>>> >>
>>> >>
>>> >>  The global deployment of RPKI, Origin Validation of BGP announcements
>>> >>  and BGPSEC, collectively called SIDR, is underway, creating an
>>> Internet
>>> >>  Routing System consisting of SIDR-aware and non-SIDR-aware networks.
>>> >>  This deployment must be properly handled to avoid the division of
>>> >>  the Internet into separate networks, ensuring as secure a routing
>>> >>  system as possible, through encouraged deployment of the SIDR
>>> technologies.
>>> >>
>>> >>  The SIDR Operations Working Group (sidr-ops) develops guidelines for
>>> >>  the operation of SIDR-aware networks, and provides operational
>>> guidance
>>> >>  on how to deploy and operate SIDR technologies in new and existing
>>> networks.
>>> >>
>>> >>  The main focuaess of the SIDR Operations Working Group are to:
>>> >>o discuss deployment and operational issues related to SIDR
>>> technologies
>>> >>  in networks which are part of the global routing system.
>>> >>o gather and discuss deployment experiences with the SIDR
>>> technologies in
>>> >>  networks which are part of the global routing system.
>>> >>
>>> >>  The goals of the sidr-ops working group are:
>>> >>
>>> >>  1.  Solicit input from network operators to identify
>>> >>  operational issues with a SIDR-aware Internet, and determine
>>> solutions
>>> >>  or workarounds to those issues.
>>> >>
>>> >>  2.  Solicit input from network operators to identify
>>> >>  operational interaction issues with the non-SIDR-aware Internet,
>>> >>  and determine solutions or workarounds to those issues.
>>> >>
>>> >

Re: [sidr] WGLC - draft-ietf-sidr-publication - ENDS: 08/18/2016 - August 18, 2016

[Christopher Morrow]

great! once I get back to the office (monday) I'll send out the upstream
request.

On Mon, Aug 22, 2016 at 8:14 AM, Oleg Muravskiy  wrote:

>
> > On 17 Aug 2016, at 01:35, Samuel Weiler  wrote:
> >
> > On Tue, 2 Aug 2016, Chris Morrow wrote:
> >
> >> Please give it a read through, and provide comments/direction in this
> thread.
> >
> > I am content to have this version of the doc be published on the
> standards track.  (Disclosure: I am the doc editor who made the most recent
> revisions to the doc.)
> >
> > -- Sam
>
> In the latest revision Sam addressed all my concerns, we have a working
> implementation, so it's good to go!
>
> Oleg
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Proposal for next steps - chartering sidrops?

[Christopher Morrow]

(fixed sidr-chairs, don't know routing-ads alias, apparently)

On Tue, Aug 23, 2016 at 10:22 AM, Christopher Morrow <
morrowc.li...@gmail.com> wrote:

> The changes from Carlos seem ok to me, and declan's points about ca/rir
> also seem on point.
> thanks! (for fixing the clearly network centric text!)
>
> On Mon, Aug 22, 2016 at 5:03 PM, joel jaeggli <joe...@bogus.com> wrote:
>
>> On 8/17/16 7:43 PM, Declan Ma wrote:
>> > Joel,
>> >
>> > When we are talking about SIDROPS,  we are referring to that BGP
>> speakers are resorting to RPKI relying party to get verified INR
>> authorization information, which is created by CA and maintained by
>> repository managers.
>> >
>> > IMHO, network operators are not the only RPKI role that the community
>> is going to solicit input from.  CA operators, repository operators, RP
>> service providers all bear significance as with SIDR Operations, in
>> identifying issues and sharing experiences.
>> Yeah there are a bunch of actors who are operators of elements other
>> than networks.
>>
>> RIRs and CAs spring immediately to mind.
>> > Although network operators could also be CA operators, repository
>> operators, RP service providers, yet RIRs, CA and repository backend
>> service providers, and third party RP don’t fall into the category of
>> ‘network operators’.
>> >
>> > I would suggest the “The goals of the sidr-ops working group” be
>> adjusted slightly, with CA operators, repository operators, RP service
>> providers involved.
>> yeah I think the tent should be inclusive.
>> >
>> > Di
>> >
>> >> 在 2016年8月18日，00:46，joel jaeggli <joe...@bogus.com> 写道：
>> >>
>> >> Folks,
>> >>
>> >> Some discussion prior to the recent IETF led us to ask the ask the
>> >> question about what to do now that SIDR is close to having achieved
>> it's
>> >> major milestones. One possible approach we have been looking at is to
>> >> Charter a new activity associated with the deployment and operation of
>> >> SIDR systems within networks. Here is an initial stab at a sidrops
>> >> charter with the milestones drawn from existing SIDR discussion.
>> >>
>> >> https://datatracker.ietf.org/doc/charter-ietf-sidrops/
>> >>
>> >>
>> >>  The global deployment of RPKI, Origin Validation of BGP announcements
>> >>  and BGPSEC, collectively called SIDR, is underway, creating an
>> Internet
>> >>  Routing System consisting of SIDR-aware and non-SIDR-aware networks.
>> >>  This deployment must be properly handled to avoid the division of
>> >>  the Internet into separate networks, ensuring as secure a routing
>> >>  system as possible, through encouraged deployment of the SIDR
>> technologies.
>> >>
>> >>  The SIDR Operations Working Group (sidr-ops) develops guidelines for
>> >>  the operation of SIDR-aware networks, and provides operational
>> guidance
>> >>  on how to deploy and operate SIDR technologies in new and existing
>> networks.
>> >>
>> >>  The main focuaess of the SIDR Operations Working Group are to:
>> >>o discuss deployment and operational issues related to SIDR
>> technologies
>> >>  in networks which are part of the global routing system.
>> >>o gather and discuss deployment experiences with the SIDR
>> technologies in
>> >>  networks which are part of the global routing system.
>> >>
>> >>  The goals of the sidr-ops working group are:
>> >>
>> >>  1.  Solicit input from network operators to identify
>> >>  operational issues with a SIDR-aware Internet, and determine solutions
>> >>  or workarounds to those issues.
>> >>
>> >>  2.  Solicit input from network operators to identify
>> >>  operational interaction issues with the non-SIDR-aware Internet,
>> >>  and determine solutions or workarounds to those issues.
>> >>
>> >>  3.  Operational solutions for identified issues should be developed
>> >>  in sidr-ops and documented in informational or BCP documents.
>> >>
>> >>  These documents should document SIDR operational experience, including
>> >>  interactions with non-SIDR-aware networks, the interfaces between
>> SIDR-aware
>> >>  and non-SIDR-aware networks, and the continued operational/security
>> impacts
>> >

Re: [sidr] Proposal for next steps - chartering sidrops?

[Christopher Morrow]

The changes from Carlos seem ok to me, and declan's points about ca/rir
also seem on point.
thanks! (for fixing the clearly network centric text!)

On Mon, Aug 22, 2016 at 5:03 PM, joel jaeggli  wrote:

> On 8/17/16 7:43 PM, Declan Ma wrote:
> > Joel,
> >
> > When we are talking about SIDROPS,  we are referring to that BGP
> speakers are resorting to RPKI relying party to get verified INR
> authorization information, which is created by CA and maintained by
> repository managers.
> >
> > IMHO, network operators are not the only RPKI role that the community is
> going to solicit input from.  CA operators, repository operators, RP
> service providers all bear significance as with SIDR Operations, in
> identifying issues and sharing experiences.
> Yeah there are a bunch of actors who are operators of elements other
> than networks.
>
> RIRs and CAs spring immediately to mind.
> > Although network operators could also be CA operators, repository
> operators, RP service providers, yet RIRs, CA and repository backend
> service providers, and third party RP don’t fall into the category of
> ‘network operators’.
> >
> > I would suggest the “The goals of the sidr-ops working group” be
> adjusted slightly, with CA operators, repository operators, RP service
> providers involved.
> yeah I think the tent should be inclusive.
> >
> > Di
> >
> >> 在 2016年8月18日，00:46，joel jaeggli  写道：
> >>
> >> Folks,
> >>
> >> Some discussion prior to the recent IETF led us to ask the ask the
> >> question about what to do now that SIDR is close to having achieved it's
> >> major milestones. One possible approach we have been looking at is to
> >> Charter a new activity associated with the deployment and operation of
> >> SIDR systems within networks. Here is an initial stab at a sidrops
> >> charter with the milestones drawn from existing SIDR discussion.
> >>
> >> https://datatracker.ietf.org/doc/charter-ietf-sidrops/
> >>
> >>
> >>  The global deployment of RPKI, Origin Validation of BGP announcements
> >>  and BGPSEC, collectively called SIDR, is underway, creating an Internet
> >>  Routing System consisting of SIDR-aware and non-SIDR-aware networks.
> >>  This deployment must be properly handled to avoid the division of
> >>  the Internet into separate networks, ensuring as secure a routing
> >>  system as possible, through encouraged deployment of the SIDR
> technologies.
> >>
> >>  The SIDR Operations Working Group (sidr-ops) develops guidelines for
> >>  the operation of SIDR-aware networks, and provides operational guidance
> >>  on how to deploy and operate SIDR technologies in new and existing
> networks.
> >>
> >>  The main focuaess of the SIDR Operations Working Group are to:
> >>o discuss deployment and operational issues related to SIDR
> technologies
> >>  in networks which are part of the global routing system.
> >>o gather and discuss deployment experiences with the SIDR
> technologies in
> >>  networks which are part of the global routing system.
> >>
> >>  The goals of the sidr-ops working group are:
> >>
> >>  1.  Solicit input from network operators to identify
> >>  operational issues with a SIDR-aware Internet, and determine solutions
> >>  or workarounds to those issues.
> >>
> >>  2.  Solicit input from network operators to identify
> >>  operational interaction issues with the non-SIDR-aware Internet,
> >>  and determine solutions or workarounds to those issues.
> >>
> >>  3.  Operational solutions for identified issues should be developed
> >>  in sidr-ops and documented in informational or BCP documents.
> >>
> >>  These documents should document SIDR operational experience, including
> >>  interactions with non-SIDR-aware networks, the interfaces between
> SIDR-aware
> >>  and non-SIDR-aware networks, and the continued operational/security
> impacts
> >>  from non-SIDR-aware networks.
> >>
> >>  SIDR operational and deployment issues with Interdomain Routing
> Protocols
> >>  are the primary responsibility of the IDR working gruop.  However, the
> >>  sidr-ops Working Group may provide input to that group, as needed, and
> >>  cooperate with that group in reviewing solutions to SIDR operational
> and
> >>  deployment problems.
> >>
> >>  Future work items within this scope will be adopted by the Working
> >>  Group only if there is a substantial expression of interest from
> >>  the community and if the work clearly does not fit elsewhere in the
> >>  IETF.
> >>
> >>  There must be a continuous expression of interest for the Working
> >>  Group to work on a particular work item.  If there is no longer
> >>  sufficient interest in the Working Group in a work item, the item
> >>  may be removed from the list of Working Group items.
> >>
> >>
> >> Feedback on this proposal and possible milestones above and beyond those
> >> currently present is appreciated before we circulate this for wider
> review.
> >>
> >> ___
> 

Re: [sidr] WGLC - draft-ietf-sidr-publication - ENDS: 08/18/2016 - August 18, 2016

[Christopher Morrow]

terrific! one vote!

more? :) (sandy's right some more folk checking through would be good, we
collected a bunch of heat about needing a different option than the
original transport, now we possibly have one...)

On Fri, Aug 12, 2016 at 8:10 PM, Randy Bush  wrote:

> have read.  have used.  wfm.
>
> randy
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-publication-08.txt

[Christopher Morrow]

Ok, since we have cycled this document a few times and the last set(s) of
comments were dealt with, I'm going to send a WGLC note, let's get chatty
on that thread?

On Mon, Mar 28, 2016 at 1:12 PM, Samuel Weiler  wrote:

> On Mon, 21 Mar 2016, Rob Austein wrote:
>
> Protocol simplification (!) per discussion with Oleg.
>>
>
> The changes in -08 are based on Oleg's astute observations that:
>
> -- per-PDU success messages aren't really helpful, especially if every
> update is tagged, and
>
> -- interleaving the list command with changes could be ambiguous and
> probably isn't useful.
>
>
> Full list of changes:
>
> -- a single success message replaces per-PDU success responses
> -- tag is now mandatory on publish/withdraw
> -- list command must standalone; cannot be combined with changes
> -- no tag on the list command, since it can't be combined
> -- added an error code for XML errors
> -- incremented the protocol version number
> -- some rearrangement of text
>
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] two stranded docuemnts - stake time

[Christopher Morrow]

On Fri, Jul 22, 2016 at 8:16 AM, Randy Bush  wrote:

> >   1) use-cases - decide on tweaks & rev-document: Aug 1
> >  review and WGLC  Aug 14
> >  send to IESG Sept 1
>
> do we have a concise issue list (other than steve not liking the style
> used)?  not sure i will make the 1 aug dreadline if i have to sift
> through the mailing list, whine, whine, whine.
>
>
My hope is that steve can (or was already going to) respond with
issues-list, so we can move along.
I presume, since he stated the issue list was short he had it on
top-of-mind :)

Steve, is there a list you were working from? could you either:
  1) send to list
  2) send to co-authors
  3) send to chairs for distribution

thanks!
-chris
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] FW: I-D Action: draft-ietf-sidr-bgpsec-protocol-17.txt

[Christopher Morrow]

thanks! :)

On Thu, Jun 23, 2016 at 10:42 AM, Sriram, Kotikalapudi (Fed) <
kotikalapudi.sri...@nist.gov> wrote:

> Many thanks to John Scudder for a very careful review of version-15 of the
> draft.
> He offered an excellent set of editorial comments to the document editors
> and shepherd.
> His email came in literally milliseconds after I had uploaded version-16
> two days ago.
> Matthias asked if the editors could make another pass at updating the
> draft in accordance with
> John's comments before he submits his shepherd report. The answer was -
> yes.
> This new version-17 incorporates John's comments (all editorial in nature).
>
> Sriram
>
> -Original Message-
> From: sidr [mailto:sidr-boun...@ietf.org] On Behalf Of
> internet-dra...@ietf.org
> Sent: Thursday, June 23, 2016 10:34 AM
> To: i-d-annou...@ietf.org
> Cc: sidr@ietf.org
> Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-17.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Secure Inter-Domain Routing of the IETF.
>
> Title   : BGPsec Protocol Specification
> Authors : Matthew Lepinski
>   Kotikalapudi Sriram
> Filename: draft-ietf-sidr-bgpsec-protocol-17.txt
> Pages   : 34
> Date: 2016-06-23
>
> Abstract:
>This document describes BGPsec, an extension to the Border Gateway
>Protocol (BGP) that provides security for the path of autonomous
>systems through which a BGP update message passes.  BGPsec is
>implemented via an optional non-transitive BGP path attribute that
>carries a digital signature produced by each autonomous system that
>propagates the update message.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-17
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-protocol-17
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01

[Christopher Morrow]

On Thu, May 5, 2016 at 5:16 PM, Carlos M. Martinez <carlosm3...@gmail.com>
wrote:

> hey!
>
> On 5/5/16 3:30 PM, Christopher Morrow wrote:
> > > I think it's an interesting topic to discuss, I'm a little worried
> > > that: "Because the third party said things are 'ok' I'll believe
> > > things are ok!"
> > >
> > > mostly because I don't see a clear method to ensure that 'third
> party' has:
> > >   1) up-to-date information
> > >
> >   Same with RTR cache server.
> >
> >
> > ​except I run the server and can get some data about how updated/etc it
> > is with respect to collection of roa/etc data.​
>
> Not always. In a couple of IXs I know the RTR server is shared and is
> provided as a service to the IXs members.
>
> They trust each other enough to do this, so not trusting the route
> server would be kind of silly.
>
>
​sure, but I dont' always use the RS at the IX.​



> In any case, you, personally as an individual IX member, are free to
> have any misgivings about the operational expertise of the IX and you
> can adjust your BGP configs accordingly (de-prefing whatever you learn
> from elbonia-ix, ignoring validation state, overwriting communities). I
> just don't see an argument against what the draft proposes in the
> scenario you describe.
>
> However, if you dis-trust a particular IX too much, maybe you just
> should de-peer them. But we disgress :-)
>

​yea, so... I didn't REALLY want to rathole the conversation. I'm perfectly
happy if consenting adults want to do this, that's cool. I may not? I may
in some places because I can't solve my problem other ways?

I don't think bending things like this is particularly bad, as long as
people understand what they walked into/on.



>
> -Carlos
>
> PS: I loved the name Elbonia, Can I license it from you ? :-)
>
>
​absolutely... Elbonia and Westonia.. they are bad places, (depending on
your perspective of course.. if you are elbonian, you dislike westonians...
and vice/versa) :)​



>
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01

[Christopher Morrow]

(as a working group person)

I think it's an interesting topic to discuss, I'm a little worried that:
"Because the third party said things are 'ok' I'll believe things are ok!"

mostly because I don't see a clear method to ensure that 'third party' has:
  1) up-to-date information
  2) my best interest at heart
  3) current/appropriate configuration

I suppose it's interesting to see another's view of the world, I don't
necessarily want to believe it myself though.


On Wed, Apr 27, 2016 at 8:11 AM, Sandra Murphy  wrote:

> The authors have requested working group adoption for
> draft-kklf-sidr-route-server-rpki-light-01, "Signaling Prefix Origin
> Validation Results from a Route-Server to Peers”.
>
> This message starts an adoption call that will end in two weeks on 11 May
> 2016.
>
> Please respond on the list to say whether you support adoption of this
> work as a working group work item AND whether you will participate in the
> discussion.
>
> Remember that working group consensus to adopt the work needs responses,
> not just absence of objection, so speak up.
>
> The draft is available at
> https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-01
>
> —Sandy, speaking as one of the wg co-chairs
>
>
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] BGPSec RFC status

[Christopher Morrow]

​
howdy, it's past 4/29/2016 || 29/4/2016 || Mar 29 2016... and from the
discussion on-list and mostly in the room in EZE, it appears:

  "Please maintain Proposed Standard as the track for SIDR work."

i think this closes out the discussion.

thanks for deliberating and discussing this topic!

-chris
co-chair

On Mon, Apr 25, 2016 at 10:53 AM, Warren Kumari  wrote:

> ... and another +1.
> W
>
>
> On Wed, Apr 20, 2016 at 4:07 AM Tim Bruijnzeels  wrote:
>
>>
>> > On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) 
>> wrote:
>> >
>> > +1 with Standard Track.
>>
>> +1
>>
>> >
>> > The question could have been relevant six years ago and we may not have
>> > debated it that much then. Today, we are clearly beyond experimental
>> draft
>> > definition and we do not want to stop people working on the topic.
>> >
>> > Roque
>> >
>> >
>> >
>> > On 14/04/16 22:20, "sidr on behalf of Geoff Huston" <
>> sidr-boun...@ietf.org
>> > on behalf of g...@apnic.net> wrote:
>> >
>> >>
>> >>> On 14 Apr 2016, at 4:17 AM, Stephen Kent  wrote:
>> >>>
>> >>> I didn't attend the IETF meeting, but I did listen to the Wednesday
>> >>> SIDR session, at
>> >>> which the issue was raised as to whether the BGPSec RFC should be
>> >>> standards track
>> >>> or experimental.
>> >>>
>> >>
>> >> I was in the room, but did not speak to this topic.
>> >>
>> >>> I believe standards track is the right approach here.
>> >>
>> >> I consulted the oracle of RFC2026 and read the following:
>> >>
>> >>  A Proposed Standard specification is generally stable, has resolved
>> >>  known design choices, is believed to be well-understood, has received
>> >>  significant community review, and appears to enjoy enough community
>> >>  interest to be considered valuable.  However, further experience
>> >>  might result in a change or even retraction of the specification
>> >>  before it advances.
>> >>
>> >> This seems to fit well, including the caveats at the end.
>> >>
>> >> On the other hand:
>> >>
>> >> The "Experimental" designation typically denotes a specification that
>> >>  is part of some research or development effort.  Such a specification
>> >>  is published for the general information of the Internet technical
>> >>  community and as an archival record of the work, subject only to
>> >>  editorial considerations and to verification that there has been
>> >>  adequate coordination with the standards process (see below).
>> >>
>> >> Which seems to fall short.
>> >>
>> >> The exercise of RFC publication of BGPSec is more than archival, and
>> the
>> >> process
>> >> has been much more than a cursory exercise of coordination with the
>> SIDR
>> >> WG. While
>> >> BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow¹s
>> >> Internet, that
>> >> future uncertainty applies to most of the IETF¹s work, and that
>> >> consideration
>> >> should not preclude its publication as a Proposed Standard, as I
>> >> interpret RFC2026.
>> >>
>> >> Geoff
>> >>
>> >>
>> >> ___
>> >> sidr mailing list
>> >> sidr@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/sidr
>> >
>> > ___
>> > sidr mailing list
>> > sidr@ietf.org
>> > https://www.ietf.org/mailman/listinfo/sidr
>>
>> ___
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>>
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] BGPSec RFC status

[Christopher Morrow]

There's been some good discussion on this, i think we (chairs) didn't
expect the list to jump on this without some prompting... but it's nice to
see :)

So, in service of 'coming to a decision' I think we should debate/discuss
for another bit, and close discussion Fri 4/29/2016 - April 29th 2016.

thanks!
-chris

On Wed, Apr 20, 2016 at 4:01 AM, Tim Bruijnzeels  wrote:

>
> > On 20 Apr 2016, at 00:31, Roque Gagliano (rogaglia) 
> wrote:
> >
> > +1 with Standard Track.
>
> +1
>
> >
> > The question could have been relevant six years ago and we may not have
> > debated it that much then. Today, we are clearly beyond experimental
> draft
> > definition and we do not want to stop people working on the topic.
> >
> > Roque
> >
> >
> >
> > On 14/04/16 22:20, "sidr on behalf of Geoff Huston" <
> sidr-boun...@ietf.org
> > on behalf of g...@apnic.net> wrote:
> >
> >>
> >>> On 14 Apr 2016, at 4:17 AM, Stephen Kent  wrote:
> >>>
> >>> I didn't attend the IETF meeting, but I did listen to the Wednesday
> >>> SIDR session, at
> >>> which the issue was raised as to whether the BGPSec RFC should be
> >>> standards track
> >>> or experimental.
> >>>
> >>
> >> I was in the room, but did not speak to this topic.
> >>
> >>> I believe standards track is the right approach here.
> >>
> >> I consulted the oracle of RFC2026 and read the following:
> >>
> >>  A Proposed Standard specification is generally stable, has resolved
> >>  known design choices, is believed to be well-understood, has received
> >>  significant community review, and appears to enjoy enough community
> >>  interest to be considered valuable.  However, further experience
> >>  might result in a change or even retraction of the specification
> >>  before it advances.
> >>
> >> This seems to fit well, including the caveats at the end.
> >>
> >> On the other hand:
> >>
> >> The "Experimental" designation typically denotes a specification that
> >>  is part of some research or development effort.  Such a specification
> >>  is published for the general information of the Internet technical
> >>  community and as an archival record of the work, subject only to
> >>  editorial considerations and to verification that there has been
> >>  adequate coordination with the standards process (see below).
> >>
> >> Which seems to fall short.
> >>
> >> The exercise of RFC publication of BGPSec is more than archival, and the
> >> process
> >> has been much more than a cursory exercise of coordination with the SIDR
> >> WG. While
> >> BGPSec may, or may not, enjoy ubiquitous deployment in tomorrow¹s
> >> Internet, that
> >> future uncertainty applies to most of the IETF¹s work, and that
> >> consideration
> >> should not preclude its publication as a Proposed Standard, as I
> >> interpret RFC2026.
> >>
> >> Geoff
> >>
> >>
> >> ___
> >> sidr mailing list
> >> sidr@ietf.org
> >> https://www.ietf.org/mailman/listinfo/sidr
> >
> > ___
> > sidr mailing list
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] BGPSec RFC status

[Christopher Morrow]

On Thu, Apr 14, 2016 at 10:05 PM, Russ White <7ri...@gmail.com> wrote:

>
> > snmp, netconf, yang, ...  heck even cops played in the space
> >
> > when your so-bgp, 15 years in the non-making, is mature as a document
> set,
> > with two or more implementations, i'll support it for standards track, no
> > problem.  i am not desperate enough to sabatoge the work of others to
> > move my work forward.
>
> Wow -- care to prove that accusation? Or have we gotten to the point in the
> IETF where personal accusations are a normal, everyday, substitute for
> actual discussion? This sort of personal abuse is what turns people away
> from the IETF, and reduces our value as a community. This is just wrong,
> Randy, and you know it is.
>
>
​​

​to be very clear, I don't think that rock tossing helps here.. in fact I
think it's distracting to the question asked. (original question I mean)
let's not toss rocks please. (either of the 2 folk on To: nor other folk on
the -list)​
​​



> My point is simple -- the "no-one will use it" argument washes either way,
> so there needs to be some other grounds for deciding -- it's not a useful
> argument in either direction, honestly. Which throws us back to what
> "standards track" actually means. On that score, I'm not certain what the
> terms mean, so I asked for clarification on what the wording actually
> means.
>
>
​I don't know exactly either, but this from 2026:

"​   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances."

doesn't:
  1) say anything about the 'Final and Ultimate Solution'
  2) that other work can't be done

In fact the last sentence implies that more work could be done and that
it's NOT the final solution.

​let's please keep to the question. I do think discussion of this topic is
interesting, to me at least, and useful for the group. My personal opinion
is that PS seems like the right answer still, even after all these years.

-chris
​
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-as-migration-04.txt

[Christopher Morrow]

howdy!

On Tue, Dec 1, 2015 at 11:38 AM, Christopher Morrow
<morrowc.li...@gmail.com> wrote:
> On Tue, Dec 1, 2015 at 11:29 AM, Christopher Morrow
> <morrowc.li...@gmail.com> wrote:
>> Unless the commentors speak up in the next 2-3 days I'll kick this
>> forward to the IESG for publication...
>
> For those that like precise dates:
>   dec 3 2015 2200 UTC (or there abouts)
>

12/3/2015 passed... I'll be shipping this northward today/monday.

thanks for the consideration and thought on the draft.

-chris

>>
>> On Fri, Oct 16, 2015 at 12:01 PM, George, Wes <wesley.geo...@twcable.com> 
>> wrote:
>>> I believe that this draft is complete and ready to move forward. This
>>> version addresses AD-review comments received at WGLC, so I think we're
>>> just waiting for it to be resubmitted to IESG for IETF LC, as the changes
>>> made were likely not substantive enough to require a new WGLC. I do *not*
>>> need time to discuss this during the meeting either.
>>>
>>> Thanks,
>>>
>>> Wes
>>>
>>>
>>>
>>>
>>> On 10/16/15, 11:53 AM, "sidr on behalf of internet-dra...@ietf.org"
>>> <sidr-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>>>
>>>>
>>>>A New Internet-Draft is available from the on-line Internet-Drafts
>>>>directories.
>>>> This draft is a work item of the Secure Inter-Domain Routing Working
>>>>Group of the IETF.
>>>>
>>>>Title   : BGPSec Considerations for AS Migration
>>>>Authors : Wesley George
>>>>  Sandy Murphy
>>>>Filename: draft-ietf-sidr-as-migration-04.txt
>>>>Pages   : 15
>>>>Date: 2015-10-16
>>>>
>>>>Abstract:
>>>>   This document discusses considerations and methods for supporting and
>>>>   securing a common method for AS-Migration within the BGPSec protocol.
>>>>
>>>>
>>>>The IETF datatracker status page for this draft is:
>>>>https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/
>>>>
>>>>There's also a htmlized version available at:
>>>>https://tools.ietf.org/html/draft-ietf-sidr-as-migration-04
>>>>
>>>>A diff from the previous version is available at:
>>>>https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-as-migration-04
>>>>
>>>>
>>>>Please note that it may take a couple of minutes from the time of
>>>>submission
>>>>until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>>Internet-Drafts are also available by anonymous FTP at:
>>>>ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>>___
>>>>sidr mailing list
>>>>sidr@ietf.org
>>>>https://www.ietf.org/mailman/listinfo/sidr
>>>
>>>
>>> 
>>>
>>> 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.
>>> ___
>>> sidr mailing list
>>> sidr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-as-migration-04.txt

[Christopher Morrow]

Unless the commentors speak up in the next 2-3 days I'll kick this
forward to the IESG for publication...

On Fri, Oct 16, 2015 at 12:01 PM, George, Wes  wrote:
> I believe that this draft is complete and ready to move forward. This
> version addresses AD-review comments received at WGLC, so I think we're
> just waiting for it to be resubmitted to IESG for IETF LC, as the changes
> made were likely not substantive enough to require a new WGLC. I do *not*
> need time to discuss this during the meeting either.
>
> Thanks,
>
> Wes
>
>
>
>
> On 10/16/15, 11:53 AM, "sidr on behalf of internet-dra...@ietf.org"
>  wrote:
>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the Secure Inter-Domain Routing Working
>>Group of the IETF.
>>
>>Title   : BGPSec Considerations for AS Migration
>>Authors : Wesley George
>>  Sandy Murphy
>>Filename: draft-ietf-sidr-as-migration-04.txt
>>Pages   : 15
>>Date: 2015-10-16
>>
>>Abstract:
>>   This document discusses considerations and methods for supporting and
>>   securing a common method for AS-Migration within the BGPSec protocol.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/
>>
>>There's also a htmlized version available at:
>>https://tools.ietf.org/html/draft-ietf-sidr-as-migration-04
>>
>>A diff from the previous version is available at:
>>https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-as-migration-04
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission
>>until the htmlized version and diff are available at tools.ietf.org.
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>ftp://ftp.ietf.org/internet-drafts/
>>
>>___
>>sidr mailing list
>>sidr@ietf.org
>>https://www.ietf.org/mailman/listinfo/sidr
>
>
> 
>
> 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.
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-as-migration-04.txt

[Christopher Morrow]

On Tue, Dec 1, 2015 at 11:29 AM, Christopher Morrow
<morrowc.li...@gmail.com> wrote:
> Unless the commentors speak up in the next 2-3 days I'll kick this
> forward to the IESG for publication...

For those that like precise dates:
  dec 3 2015 2200 UTC (or there abouts)

>
> On Fri, Oct 16, 2015 at 12:01 PM, George, Wes <wesley.geo...@twcable.com> 
> wrote:
>> I believe that this draft is complete and ready to move forward. This
>> version addresses AD-review comments received at WGLC, so I think we're
>> just waiting for it to be resubmitted to IESG for IETF LC, as the changes
>> made were likely not substantive enough to require a new WGLC. I do *not*
>> need time to discuss this during the meeting either.
>>
>> Thanks,
>>
>> Wes
>>
>>
>>
>>
>> On 10/16/15, 11:53 AM, "sidr on behalf of internet-dra...@ietf.org"
>> <sidr-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
>>
>>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts
>>>directories.
>>> This draft is a work item of the Secure Inter-Domain Routing Working
>>>Group of the IETF.
>>>
>>>Title   : BGPSec Considerations for AS Migration
>>>Authors : Wesley George
>>>  Sandy Murphy
>>>Filename: draft-ietf-sidr-as-migration-04.txt
>>>Pages   : 15
>>>Date: 2015-10-16
>>>
>>>Abstract:
>>>   This document discusses considerations and methods for supporting and
>>>   securing a common method for AS-Migration within the BGPSec protocol.
>>>
>>>
>>>The IETF datatracker status page for this draft is:
>>>https://datatracker.ietf.org/doc/draft-ietf-sidr-as-migration/
>>>
>>>There's also a htmlized version available at:
>>>https://tools.ietf.org/html/draft-ietf-sidr-as-migration-04
>>>
>>>A diff from the previous version is available at:
>>>https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-as-migration-04
>>>
>>>
>>>Please note that it may take a couple of minutes from the time of
>>>submission
>>>until the htmlized version and diff are available at tools.ietf.org.
>>>
>>>Internet-Drafts are also available by anonymous FTP at:
>>>ftp://ftp.ietf.org/internet-drafts/
>>>
>>>___
>>>sidr mailing list
>>>sidr@ietf.org
>>>https://www.ietf.org/mailman/listinfo/sidr
>>
>>
>> 
>>
>> 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.
>> ___
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Christopher Morrow]

On Mon, Nov 23, 2015 at 5:13 PM, Christopher Morrow
<morrowc.li...@gmail.com> wrote:
> Pinging this thread to catch anyone who didn't reply but had thoughts
> I'd like to close this out tomorrow before 5pm EST (10pm UTC).
>

Damn my lack of date specificity!!
  To be clear, I'd like to make the call on this:
2015-11-25 10pm UTC
   (November 25 2015 10pm UTC)

> thanks!
> -chris
>
> On Sat, Nov 21, 2015 at 9:24 AM, Randy Bush <ra...@psg.com> wrote:
>>> the intent is an appropriate change to improve robustness of the
>>> system.
>>
>> i think it changes the robustness, not necessarily improves it.  the
>> loss of congruent hierarchic validation is exchanged for accepting some
>> failures we have yet to see.
>>
>> being a bit of a naggumite, accepting errors is not big on my agenda.
>> one of my disagreements with dr postel was the receiver side of the
>> robustness principle.  this way lies entropic death.
>>
>> randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Christopher Morrow]

Pinging this thread to catch anyone who didn't reply but had thoughts
I'd like to close this out tomorrow before 5pm EST (10pm UTC).

thanks!
-chris

On Sat, Nov 21, 2015 at 9:24 AM, Randy Bush  wrote:
>> the intent is an appropriate change to improve robustness of the
>> system.
>
> i think it changes the robustness, not necessarily improves it.  the
> loss of congruent hierarchic validation is exchanged for accepting some
> failures we have yet to see.
>
> being a bit of a naggumite, accepting errors is not big on my agenda.
> one of my disagreements with dr postel was the receiver side of the
> robustness principle.  this way lies entropic death.
>
> randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Validation Reconsidered (again/again) question

[Christopher Morrow]

Please take 2 weeks time to consider:

"This document was adopted as a WG work item, should we accept this
change and complete the work or not?"

where:
  'this document' is:
   


I'll close the mic line on: 11/20/2015
Nov 20, 2015

-Chris
sidr-co-chair

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation reconsidered draft status

[Christopher Morrow]

hurray! ambiguity in questions was raised by an interested party...

I'd rather do this Friday at the end of the meeting with a short
presentation/conversation.

-chris

On Tue, Nov 3, 2015 at 8:21 PM, Christopher Morrow
<christopher.mor...@gmail.com> wrote:
> During the meeting today (tues 11/3/2015) one of the authors of:
>   draft-ietf-sidr-rpki-validation-reconsidered
>
> noted that after the last set of updates and over the history of the
> document (2+yrs) there's been no real support nor direction from the
> working-group. Additionally, all co-authors noted that the lack of
> support and direction meant that abandoning the draft seemed like the
> best current direction.
>
> The primary author: Geoff Huston (g...@apnic.net) is willing to toss
> the XML over the fence to another author/editor if there is interest,
> or to let the draft expire/die if no one is willing to take up the
> pencil.
>
> Over the next three weeks let's discuss the direction/end-goal and
> determine if 'abandon' or 'new author' is the best course of action
> here.
>
> -chris
> sidr-co-chair

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Validation reconsidered draft status

[Christopher Morrow]

During the meeting today (tues 11/3/2015) one of the authors of:
  draft-ietf-sidr-rpki-validation-reconsidered

noted that after the last set of updates and over the history of the
document (2+yrs) there's been no real support nor direction from the
working-group. Additionally, all co-authors noted that the lack of
support and direction meant that abandoning the draft seemed like the
best current direction.

The primary author: Geoff Huston (g...@apnic.net) is willing to toss
the XML over the fence to another author/editor if there is interest,
or to let the draft expire/die if no one is willing to take up the
pencil.

Over the next three weeks let's discuss the direction/end-goal and
determine if 'abandon' or 'new author' is the best course of action
here.

-chris
sidr-co-chair

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] [Idr] Route Leaks and solutions

[Christopher Morrow]

I think I see the current plan as a it challenging to depend upon...

If the RLP bit is dependent upon ops folks getting the right
config-bit set for each customer we would want that to be as much
automated as possible so there would be the least chance for 'forgot
to set the bit' or 'set bit incorrectly'.

I'm worried that I can't tell reliably what the bit was 2 as-hops
away, did they mean 'customer' ? or was that a mistake? Did someone
change it mid-path to me? Did the implementation of their vendor gear
change/set the wrong attribute value?

There seem to be a bunch of uncertainties with this, in my mind. I
guess that with bgpsec signing this attribute at least 'joe really
meant that jim was his customer', and you can't change the value on a
bgpsec path.

If we want that, I think having the attribute where it can get changed
(not-bgpsec secured paths) is a real problem, or opens up some pretty
large problems...

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12

[Christopher Morrow]

I think this means you are asking for a WGLC, yes?
If so we can ship a note to the list (here) about that...

On Mon, Jun 15, 2015 at 12:41 AM, Matthew Lepinski
mlepinski.i...@gmail.com wrote:
 I have submitted a new version of the BGPsec protocol specification.

 This version includes some minor fixes as well as all of the changes
 discussed at IETF 92. (Minutes can be found here --
 http://www.ietf.org/proceedings/92/minutes/minutes-92-sidr) I believe that
 all open issues with this document have been addressed.

 The only normative changes in the -12 version are the following:
 -- BGPsec speakers MUST support the multi-protocol extension (RFC 4760)
 -- BGPsec now signs the entire MP_REACH_NLRI attribute. (Recall that there
 was an error previously where the AFI was not protected under the signature)

 I believe that this document is now ready to ship to the IESG. If you
 disagree, please let me know what still needs to be addressed.

 - Matt Lepinski

 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] LTA Management and friend(s): draft-ietf-sidr-ltamgmt

[Christopher Morrow]

An off-list post reminded me:

draft-ietf-sidr-lta-use-cases-02.txt

is still of interest and probably should get worked on prior to slurm.
(at least so we know why we'll be interested in slurm)


On Mon, Jun 1, 2015 at 5:11 PM,  m...@islandpeaksoftware.com wrote:
 LTAmgmt: destroy it, destroy it utterly. Laugh and scream with joy at its

 termination.



 On Mon, 01 Jun 2015 17:07:56 -0400, Stephen Kent k...@bbn.com wrote:

 yes, please put a stake in it!

 Steve
 Howdy SIDR folks,

 This draft expired:
 http://tools.ietf.org/wg/sidr/draft-ietf-sidr-ltamgmt/

 I think this is proper, given the discussion on-list and in-person, we
 seem to have moved away from the world of LTA management and on to:

 slurm: http://tools.ietf.org/id/draft-dseomn-sidr-slurm-02.txt

 Should we officially put the wooden stake into LTAmgmt and ask for
 adoption for slurm?

 -chris
 sidr-co-chair-personage.

 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr


 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr




 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Correction re: draft-ietf-sidr-lta-use-cases

[Christopher Morrow]

could I suggest that:
  A ... is a bit rough on the reader in sentences like:
  A wants to re-route traffic from these organizations...

A what? a giraffe? oh! Entity-A (or Network-A).. maybe change 'A' to
'Entity-A' or 'Network-A' ? Also there's a sad choice of time to use a
pronoun in your example:

Organization A is authorized to control the routing of traffic from a
set of organizations (within A's administrative control) to the rest
of the Internet. A wants to re-route traffic from these organizations
that is destined for a set of systems outside of A's administrative
control to a set of systems under its control, or to have that traffic
dropped.

What is 'its' there? Org-A? his customers? the systems? generally it
would be better to be clear and not use pronouns.

On Wed, Apr 8, 2015 at 9:34 PM, Declan Ma m...@zdns.cn wrote:
 Karen,

 This is indeed a better description.

 And I believe it would be even better if Randy could describe how a local 
 trust anchor” takes effect on different cases.


 Declan Ma

 ZDNS Ltd.



 在 2015年4月4日，上午2:18，Karen Seo k...@bbn.com 写道：

 Folks,

 Here's a better description of Case 3. (Thanks go to David Mandelberg for 
 catching the problems with the previous version.)
 Case 3:
 Organization A is authorized to control the routing of traffic from a set of 
 organizations (within A's administrative control) to the rest of the 
 Internet. A wants to re-route traffic from these organizations that is 
 destined for a set of systems outside of A's administrative control to a set 
 of systems under its control, or to have that traffic dropped. A 
 accomplishes this by controlling the UPDATES (for the routes to the 
 addresses for those systems) that are sent to those organizations. If these 
 organizations use the RPKI, A needs a way to ensure the information they 
 obtain from the RPKI supports A’s traffic management goals.

 For example, Alice runs the network operations for a large consortium C that 
 operates AS Y. Her management requests that traffic from C's members that is 
 destined for a competitor's server at address Q in AS X, be re-directed to 
 one of C's servers in AS Y.  To do this, Alice assigns address Q to a server 
 in AS Y and has AS Y originate routes for address Q. Alice has to ensure 
 that the RPKI has the appropriate certificates, ROAs, etc. for these 
 approved routes, as well as for the rest of the Internet.
 Karen

 On 3/10/15 1:38 AM, Karen Seo wrote:
 Randy et al.,

 In hopes of restarting work on this draft, here is proposed text for 
 section 4. This is an attempt to integrate the original text with the 
 comments to the list submitted back in Feb 2014.  My apologies if I've 
 mis-understood the original draft text or the comments.  Does this 
 correctly and clearly describe the use cases?

 4.  Use Cases

 Case 1:
 Organization C finds that its CA certificate has been revoked (or modified 
 to remove resources) by the RIR (or ISP) that issued it. Or, if C has 
 outsourced its CA operations, C finds that one of its children's 
 certificates has been revoked (or modified to remove resources). C 
 disagrees with this action and would like relying parties to be able to 
 ignore, at their discretion, the certificate revocation (or modification). 
 The revocation or modification could be:
  • unintentional, i.e., due to an error by RIR (or ISP) staff
  • malicious, i.e., done with the intent to cause problems, which could 
 be aimed at C or some other entity.
  • mandated by a law enforcement agency in the jurisdiction where the 
 RIR (or ISP) operates
 For example, Carol, a RIPE resource holder (LIR, PI holder, ...), is a 
 victim of the Dutch Court Attack. Someone has convinced a Dutch court to 
 force the RIPE/NCC to remove or modify some or all of Carol's certificates, 
 ROAs, etc. or the resources they represent. However, the operational 
 community wants to retain the ability to route to Carol's network(s).

 Case 2:
 Organization B makes use of private address space (RFC 1918) or address 
 space allocated to another party but not globally announced by that party 
 or by B. B wants its routers to be able to use RPKI data for both internal 
 routing to these addresses and for global routing.

 Case 3:
 Organization A is authorized to control the routing of traffic from a set 
 of organizations (within A's administrative control) to the rest of the 
 Internet. A wants traffic from these organizations that is destined for a 
 set of prefixes outside of A's administrative control to be routed to other 
 addresses, or to be dropped. A accomplishes this by controlling the UPDATEs 
 sent to those organizations. Because these organizations use the RPKI, A 
 needs a way to coordinate their use of the RPKI in support of A’s traffic 
 management goals.

 For example, Alice runs the network operations for a large consortium X. 
 Her management requests that traffic (from X's members) that is destined 
 for a competitor's site, be re-directed 

Re: [sidr] AD review and progressing draft-ietf-sidr-as-migration-02

[Christopher Morrow]

sounds like a good topic for the mic/front/preso in dallas... to me at least.

On Sat, Feb 7, 2015 at 9:34 AM, George, Wes wesley.geo...@twcable.com wrote:
 I posed some questions about this in my WGLC review of bgpsec spec, but
 haven't heard anything back. Current schedule has this being evaluated by
 IESG prior to our next meeting. If we need to discuss during the meeting
 in Dallas, we could certainly delay processing of the document. It has a
 normative block on the bgpsec spec, so it's not like it's getting
 published right away anyway.

 Thanks,

 Wes



 On 2/6/15, 11:15 AM, Randy Bush ra...@psg.com wrote:

has the wg really looked at 5.2 and 5.3 with respect to how the ibgp
hacks affect the bgpsec spec?

randy


 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.
 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10

[Christopher Morrow]

On Mon, Nov 24, 2014 at 3:08 PM, Smith, Donald
donald.sm...@centurylink.com wrote:
 Wouldn't GTSM and tcp-ao help with DOS attacks?


I think this was focused only on the uplift to bgp that bgpsec is
supposed to be, so the assumption was/is that you'd already be doing
'bgp best practices'.

(authors are free to correct me, as always)
-chris

 I would recommend they be put in in the paragraph below.

 7.3 Mitigation of Denial of Service Attacks

 BGPSEC speakers
should implement an update validation algorithm that performs
expensive checks (e.g., signature verification) after performing less
expensive checks (e.g., syntax checks).  The validation algorithm
specified in Section 5.2 was chosen so as to perform checks which are
likely to be expensive after checks that are likely to be
inexpensive.



 https://tools.ietf.org/html/rfc5082



 https://tools.ietf.org/html/rfc5925



 As examples or recommendations for the less expensive checks.



 In fact it should be GTSM, tcp-ao THEN bgpsec validation.







 (coffee != sleep)  (!coffee == sleep)
  donald.sm...@centurylink.com
 
 From: sidr [sidr-boun...@ietf.org] on behalf of Stephen Kent [k...@bbn.com]
 Sent: Monday, November 24, 2014 12:35 PM
 To: sidr@ietf.org
 Subject: Re: [sidr] New version : draft-ietf-sidr-bgpsec-protocol-10

 Wes,

 To first order I agree with your concern of this DoS vulnerability,
 but with some minor clarifications.

 1. BGPsec-signed updates are sent only between ASes that agree to
 send and receive (separate choices) this signed data. So, an
 attack of this sort is perpetrated only against an immediate neighbor
 that agrees to accept BGPsec traffic from you. You cannot send
 a BGPsec route to an arbitrary AS that it not configured for you
 as a neighbor.

 2. As you noted, an AS can generate a path only for ASes that it
 holds, and thus, for which it holds private keys. So, a long path
 of the sort you describe is directly traceable to the resources holder,
 creating a smoking gun effect, for forensic purposes.

 If we can agree on a max path length, based on real world data, and
 RECOMMEND that routers enforce this limit, we can mitigate the
 ability of an AS to Dos it's neighbor (and others). That, combined with
 the ability to identify who added all of the questionable AS entries,
 might provide a deterrent to this behavior.

 Still, even with a max path length, there is the potential to add just a
 few,
 unnecessary ASes to every signed route that traverses an evil AS, to add to
 the burden of neighbors and those beyond. Given all the folks who track
 routing updates, this too will probably be noted by a bunch of folks, and
 because of the signatures, there will be no doubt about the source(s). So,
 here too, that may prove to be a deterrent.

 I believe someone at the meeting observed that smart implementations will
 try to address this sort of concern by postponing BGPsec crypto processing
 when resources get scarce. While I agree that this represents another attack
 vector, the ability to identify the perpetrators may diminish the attraction
 of this attack strategy.

 In any case, this is a good topic to address, perhaps in the BGPsec
 security considerations section, plus a separate document that suggests
 implementation notes.

 Steve

 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr
 This communication is the property of CenturyLink and may contain
 confidential or privileged information. Unauthorized use of this
 communication is strictly prohibited and may be unlawful. If you have
 received this communication in error, please immediately notify the sender
 by reply e-mail and destroy all copies of the communication and any
 attachments.

 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] [Idr] A note from today's IDR/SIDR joint meeting - RPKI-RTR protocol document

[Christopher Morrow]

On Mon, Nov 17, 2014 at 4:32 AM, Roque Gagliano (rogaglia)
rogag...@cisco.com wrote:
 Chis,

 The document is now RFC 6912 published as BCP.

great! (I should have looked further along the line in the tools page I bet)


 Regards,
 Roque

 On 14/11/14 21:00, Christopher Morrow christopher.mor...@gmail.com
 wrote:

Also there was a question (from hannes?) about algorithm change
processes and timelines.. that's covered in:
  https://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-12

-chris

On Fri, Nov 14, 2014 at 2:50 PM, Christopher Morrow
christopher.mor...@gmail.com wrote:
 The topic of getting 'rpki data to routers' is covered in the
 'rpki-rtr' document:
 RFC6810 - http://tools.ietf.org/html/rfc6810

 and:
   http://tools.ietf.org/wg/sidr/draft-ietf-sidr-rpki-rtr-rfc6810-bis/

 -chris

___
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] A note from today's IDR/SIDR joint meeting - RPKI-RTR protocol document

[Christopher Morrow]

The topic of getting 'rpki data to routers' is covered in the
'rpki-rtr' document:
RFC6810 - http://tools.ietf.org/html/rfc6810

and:
  http://tools.ietf.org/wg/sidr/draft-ietf-sidr-rpki-rtr-rfc6810-bis/

-chris

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] A note from today's IDR/SIDR joint meeting - RPKI-RTR protocol document

[Christopher Morrow]

Also there was a question (from hannes?) about algorithm change
processes and timelines.. that's covered in:
  https://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-12

-chris

On Fri, Nov 14, 2014 at 2:50 PM, Christopher Morrow
christopher.mor...@gmail.com wrote:
 The topic of getting 'rpki data to routers' is covered in the
 'rpki-rtr' document:
 RFC6810 - http://tools.ietf.org/html/rfc6810

 and:
   http://tools.ietf.org/wg/sidr/draft-ietf-sidr-rpki-rtr-rfc6810-bis/

 -chris

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Violation of RFC 6811 - Route Selection Algorithm Due To RPKI State

[Christopher Morrow]

On Tue, Nov 11, 2014 at 1:17 AM, Mark Tinka mark.ti...@seacom.mu wrote:
 Hello all.

 In operating RPKI on Cisco IOS and IOS XE devices, we note
 that this vendor is deliberately making BGP best path
 decisions based on RPKI state of a route without the
 explicit input of operator-based routing policy.

ro-ro-shaggy... that seems like a poor plan.


 So in addition to the normal (i.e., historically known) BGP
 best path decision process, the presence of an RTR session
 causes this vendor to, by default, add RPKI state to the BGP
 best path decision process when there does not exist a
 routing policy initiated by the operator to do so.

oh.. that's super not cool.


 This is in violation of RFC 6811, Section 2, which clearly
 states:

 An implementation MUST NOT exclude a route from the
  Adj-RIB-In or from consideration in the decision
  process as a side effect of its validation state,
  unless explicitly configured to do so.

 Official documentation from the vendor confirms this default
 behaviour as well:

 http://tinyurl.com/pqpjmen


sad panda

 While the vendor provides knobs to disable this default
 behaviour, operators could generally miss this information.
 And given that there is no clear reason why a normally
 best path would be rejected on grounds of RPKI state not
 initiated by the operator, this is a hard problem to
 troubleshoot, even with prior (working) knowledge of RPKI.


sorry :(

 Cheers,

 Mark.

 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC - draft-ietf-sidr-as-migration

[Christopher Morrow]

Seeing some more folk comment on this, and seeing that the IDR pair document:
  draft-ietf-idr-as-migration-03

is headed out to publication request as well, let's close this WGLC
and move this document along as well.

-chris

On Tue, Sep 30, 2014 at 10:28 AM, George, Wes wesley.geo...@twcable.com wrote:
 On 9/29/14, 9:18 PM, Randy Bush ra...@psg.com wrote:


 1. Figures 3 and 4 from the companion I-D draft-ietf-idr-as-migration
are referenced several times in this document. It would be easier
for the readers if those two figures are reproduced in this
document when they are first referenced.

uh, having data in two places is a recipe for trouble.  this is why we
do references.  i really don't like copy and paste between docs.  but
perhaps i am alone in this.

 WG] I agree, my preference is to leave the diagrams in the referenced
 document, and assume that those reviewing can manage to have two parallel
 windows open (one of the few places where IETF's self-imposed text-width
 restrictions come in handy) or briefly commit the high-quality ASCII
 diagrams to memory.

 Sriram, I'll incorporate the rest of your feedback into my next version,
 which will likely be posted either at IETF LC or due to directorate review.

 Thanks for giving it another look

 Wes


 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.
 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC - draft-ietf-sidr-as-migration

[Christopher Morrow]

Helo from sidr-co-chair:
Are there no more comments and concerns and improvements and Hey,
awesome draft! things to be said about this draft?

With no input it's a tad hard to judge the quality of the draft and
it's applicability to SIDR in general...

-chris
(note, I've read the draft and think it's helpful to migrating
operational networks together... in a land where SIDR is in play)

On Fri, Sep 12, 2014 at 10:29 AM, Christopher Morrow
morrowc.li...@gmail.com wrote:
 Boo! people ought to read and write.. it's friday! take some time to
 review and make sure there's not like mistakes and stuff in this, eh?
 :)

 (please? :) )

 -chris

 On Thu, Aug 28, 2014 at 10:46 AM, Chris Morrow morr...@ops-netman.net wrote:
 Howdy SIDR folken,
 It's time again to dust off your spectacles and dive into a wonderous
 world of 'potential RFC' reading material!!

 It'd be great if we could start this WGLC today:
   8/28/2014 or
   August 28 2014 or
   the 240th day of this year 2014

 and end it in 2 weeks time on:
   9/11/2014
   September 11, 2014
   the 254th day of this year 2014


 for the draft in the subject line: draft-ietf-sidr-as-migration
 the abstract of which is copied herein for your convenience:

   This draft discusses considerations and methods for supporting and
securing a common method for AS-Migration within the BGPSec
protocol.


 This document's pair is in IDR WGLC at this time as well, that document is:
   http://tools.ietf.org/html/draft-ietf-idr-as-migration

 happy reading and please send comments/concerns/adulation to the list.

 -chris
 wg-co-chair

 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[Christopher Morrow]

Ok, with an offline (off email?) conversation with one of the authors
I think it's time to call an end to this very long WGLC.

It seems, to me, that all of the comments and questions were dealt
with, and that overall the document is ready to move along to the next
step in the ponderous (though probably shorter than this step)
process.

Thanks for bearing with the process so far...

-chris
co-chair-person

On Wed, May 21, 2014 at 3:59 PM, Christopher Morrow
morrowc.li...@gmail.com wrote:
 On Wed, May 21, 2014 at 3:53 PM, Randy Bush ra...@psg.com wrote:
 ok, so we're just holding on roque then?

 no.  i know how to deal with that one.  but i do not want to make
 multiple updates.  so waiting for wglc to finish (actually, i think
 it timed out already), so i can issue one hack.

 yes, it dragged out waiting on some wording fixes...

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[Christopher Morrow]

On Wed, May 21, 2014 at 3:18 PM, George, Wes wesley.geo...@twcable.com wrote:

 On 5/20/14, 10:38 AM, Randy Bush ra...@psg.com wrote:

  we got past
folk looking up 'per se' in their dictionaries.

 Well not exactly, since that was never the initial problem. I just decided
 not to make an issue out of it any further since I seemed to be the only
 one expressing the concern.

ok, so we're just holding on roque then?

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[Christopher Morrow]

On Wed, May 21, 2014 at 3:53 PM, Randy Bush ra...@psg.com wrote:
 ok, so we're just holding on roque then?

 no.  i know how to deal with that one.  but i do not want to make
 multiple updates.  so waiting for wglc to finish (actually, i think
 it timed out already), so i can issue one hack.

yes, it dragged out waiting on some wording fixes...

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[Christopher Morrow]

i didn't update the tracker... (i hadn't ever in the past).

Did we circle down on an answer for the leak/persay language that
everyone's happy with? If so I'd like to push out a pub request today.

On Tue, May 20, 2014 at 9:52 AM, Randy Bush ra...@psg.com wrote:
 funny.  datatracker does not show wglc for this document

 randy, trying to time that small fix for roque

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[Christopher Morrow]

On Tue, May 20, 2014 at 10:38 AM, Randy Bush ra...@psg.com wrote:
 i didn't update the tracker... (i hadn't ever in the past).

 uh, that is between you and the datawhacker

 Did we circle down on an answer for the leak/persay language that
 everyone's happy with? If so I'd like to push out a pub request today.

 as far as i am aware, there is no issue with leak language.  we got past
 folk looking up 'per se' in their dictionaries.  the one open issue is

3.14  While the trust level of a route should be determined by the
  BGPsec protocol, local routing preference and policy MUST 
 then
  be applied to best path and other routing decisions.  Such
  mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt].
  ...
3.17  If a BGPsec design makes use of a security infrastructure, 
 that
  infrastructure SHOULD enable each network operator to select
  the entities it will trust when authenticating data in the
  security infrastructure.  See, for example,
  [I-D.ietf-sidr-ltamgmt].
 
  What about adding that the connection to this security infrastructure
  MUST be through a secure channel?
 
  it's done via rcynic and/or rpki-to-rtr, right? depending on where in
  the process you are... presuming the process looks like:
publication-point - gatherer - cache - router
(rcynic) (rcynic)   (rpki-rtr)

 apologies to roque.  some external data were indeed what was meant (an
 rpki-like thing is an example), and was inteneded by security
 infrastructure.

 the authenticity of those data is an issue.  we might say so in sec
 cons.

 and i am waiting for wglc to close so i can make the hack once.

Roque, is the change/text ok? or ?

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Questions about draft-huston-rpki-validation-01

[Christopher Morrow]

On Tue, May 20, 2014 at 8:10 AM, Geoff Huston gih...@gmail.com wrote:

 On 20 May 2014, at 4:38 am, Christopher Morrow morrowc.li...@gmail.com 
 wrote:

 It's unclear to me what would happen if you split this into a
 prefix/asn per cert and just carried more certs in your purse. Why
 would I not just add more certs to my purse? is there a particular
 reason to conglomerate these under the minimal number of certs? are we
 trying to minimize space in my purse? if so the purse is large, and
 the certs very small... I could 10x or 100x the number of certs here
 and be ok still.

 For AS numbers thats an interesting approach, if you carry a single ASN per 
 cert then yes, there would be a whole lot more certs around (-ve), but any 
 discrepancy in AS registry records between parent and child would be limited 
 to just those ASns where there are such discrepancies (+ve)


ok, in tim's/your(someone's) original note:
- snip 
Certificate 1: {10.0.0.0/12, AS64501, AS64505, AS64509}  (TA certificate)
Certificate 2: {10.0.0.0/22, AS64501, AS64505, AS64511}
Certificate 3: {10.0.0.0/20, AS64501, AS64509}

Currently we reject certificate 2 and everything under it..
- end snip 

it looks to me like making this 8 ROA instead of 3 would make sense.
The 'isp'/resource-owner (I think - AS64501) would be able to announce
the /12, /22 and /20. The customer/other prefix-users:
   64505 - /12 and /22
   64509 - /12 and /20
   64511 - /22

which seems to catch the intent of the 3 certs at least. This way if
you were to break out a new /X from the /12 for AS65534  no one is
broken and no shuffling has to happen (yet).

If the RIR would break the /12 up into 2x /13, for instance, and
transfer the top/higher /13 off to RIR#2, only the /12 needs to change
and you could do make-before-break over some period of time acceptable
to the 3+ parties involved.

Additionally, if the RIR has an oopsy on the /12 the other prefixes by
the users are ok... hopefully.

It's not clear to me that 'oopsy' will happen on only a single prefix
either? if it can happen to 1, it can happen to 2. (maybe that's a
chat for another day in the thread though).

 However I'm unsure how you could or would apply this principle to IPv4 
 addresses. And I'm even more unclear about IPv6.


to /32's? or something else? I suppose TODAY we only really care about
'minimum size prefix (max length) which is globally accepted'. We also
should have data on how quickly the RPKI system converges across it's
whole (perhaps to some level of 'converge') given number of objects in
the global system. (this metric discussion came up several times over
the last M meetings... sriram and tim have some data, but it's not
clear how applicable any of the study work has been)

 However, in principle, the validation algorithm proposed in this draft 
 performs a validation function which is semantically equivalent to breaking 
 down each certificate into a collection of certificates, each describing one 
 element of the original number set, but this approach does not require one to 
 define the minimal unit of addresses in IPv6, nor try to generate an 
 enumeration of individual /128s (or even /64s!) in IPv6, which I guess is a 
 Good Thing.

sure, but I don't know that we need to go to host-level data do we?
you can't get a host-route routed in the internet today, at least not
beyond your local ISP (save leaks/mistakes), and I think the ROA
format allows you to specify:
  128.2.0.0/16-32 AS5050

right? so in v6:
  2001:4860::/32-128 AS15169

Any case of splitting a prefix (2001:4860::/32  becomes 2001:4860::/33
 2001:4860:8000::/33) for the purposes of transfer/change-in-Origin
is going to require /make before break. I don't think that's changed
by the validation algorithm is it?

I do think that being explicit with the roa content and not cute by
chunking as much as possible into the bag is a good thing. It seems,
to me, like it makes the decision process for each ROA less complex,
and thus any further actions on that ROA (splits, joins, deletion,
etc) simpler.

-chris

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Questions about draft-huston-rpki-validation-01

[Christopher Morrow]

On Thu, Apr 17, 2014 at 11:35 AM, Tim Bruijnzeels t...@ripe.net wrote:
 Certificate 1: {10.0.0.0/12, AS64501, AS64505, AS64509}  (TA certificate)
 Certificate 2: {10.0.0.0/22, AS64501, AS64505, AS64511}
 Certificate 3: {10.0.0.0/20, AS64501, AS64509}

It's unclear to me what would happen if you split this into a
prefix/asn per cert and just carried more certs in your purse. Why
would I not just add more certs to my purse? is there a particular
reason to conglomerate these under the minimal number of certs? are we
trying to minimize space in my purse? if so the purse is large, and
the certs very small... I could 10x or 100x the number of certs here
and be ok still.

-chris

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04

[Christopher Morrow]

On Mon, May 5, 2014 at 12:10 PM, Roque Gagliano (rogaglia)
rogag...@cisco.com wrote:
 Sandra,

 I support this document moving forward to the IESG.

 I read the document as part of the WGLC process and I believe the text is
 ready for publication.

 My only question is a formality from Section 3 that says:

  If a BGP router supports prefix origin validation and is configure for the
 extensions defined in this document, the validation step SHOULD be performed
 prior to any of the steps defined in the decision process of [RFC4271].

 (Roque) Should this document specifically be labeled as an update to
 RFC4271?

doesn't a prefix-list (or other route-filter) happen prior to the
decision process as well though?


 Regards,
 Roque

 On Apr 26, 2014, at 1:53 AM, Sandra Murphy sa...@tislabs.com wrote:

 The authors of BGP Prefix Origin Validation State Extended Community,
 draft-ietf-sidr-origin-validation-signaling-04 have requested a WGLC.

 This message begins a two week WGLC, to end on 9 May 2014.

 The draft is available at
 http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling.

 Please do send comments to the list, indicating whether you do or do not
 believe that the draft is ready for publication.

 --Sandy, speaking as wg co-chair
 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr



 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[Christopher Morrow]

On Mon, May 5, 2014 at 12:41 PM, Randy Bush ra...@psg.com wrote:
   3.14  While the trust level of a route should be determined by the
 BGPsec protocol, local routing preference and policy MUST then
 be applied to best path and other routing decisions.  Such
 mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt].
 ...
   3.17  If a BGPsec design makes use of a security infrastructure, that
 infrastructure SHOULD enable each network operator to select
 the entities it will trust when authenticating data in the
 security infrastructure.  See, for example,
 [I-D.ietf-sidr-ltamgmt].

 What about adding that the connection to this security infrastructure
 MUST be through a secure channel?

it's done via rcynic and/or rpki-to-rtr, right? depending on where in
the process you are... presuming the process looks like:
  publication-point - gatherer - cache - router
  (rcynic) (rcynic)   (rpki-rtr)


and above/before 'publication-point' is 'RIR tomfoolery'

 connection from what?  mains power?  :)

i think roque was referring to the above process...which I think
already includes 'security bits'. (rcynic == CMS, rpki-rtr == AO ||
ssh)

 this is about routers speaking bgpsec.  imiho, it would be ill-adviised
 to start down the rat-hole of operational practices of router management
 for which there is no proof of termination.

let's avoid that for now, especially since I think the request is
already taken care of.

If this is all satisfactory, let's get to a WGLC in the next 2 days,
and then see where that leads us?

-chris

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[Christopher Morrow]

coming back to this discussion...

On Fri, Feb 7, 2014 at 10:17 PM, Randy Bush ra...@psg.com wrote:
 perhaps people should use a dictionary and look up per se.

(from dictionary.com, or wherever bing.com 'define per se' comes from)
per se
1. by or in itself or themselves; intrinsically.

so, as I read the original:

  As noted in the threat model, [I-D.ietf-sidr-bgpsec-threats], this
   work is limited to threats to the BGP protocol.  Issues of business
   relationship conformance, of which routing 'leaks' are a subset,
   while quite important to operators (as are many other things), are
   not security issues per se, and are outside the scope of this
   document.  It is hoped that these issues will be better understood in
   the future.

I could easily replace per se with 'intrinsically' like:
  As noted in the threat model, [I-D.ietf-sidr-bgpsec-threats], this
   work is limited to threats to the BGP protocol.  Issues of business
   relationship conformance, of which routing 'leaks' are a subset,
   while quite important to operators (as are many other things), are
   not intrinsically security issues, and are outside the scope of this
   document.  It is hoped that these issues will be better understood in
   the future.


Is there a reason to keep the mention of route-leaks in this document?
Could we go with:

  As noted in the threat model, [I-D.ietf-sidr-bgpsec-threats], this
   work is limited to threats to the BGP protocol.  Issues of business
   relationship conformance, while quite important to operators, are
   not security issues per se, and are outside the scope of this
   document.  It is hoped that these issues will be better understood in
   the future.

I think this was in line with warren's suggestion, which wes agreed
with as did stephen kent. This seems ok to me as well... I'd like to
close the discussion sooner rather than later and send out a
publication request.

-chris

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

[Christopher Morrow]

On Mon, Apr 14, 2014 at 11:00 AM, Randy Bush ra...@psg.com wrote:
 while checking the docco, i found

3.14  While the trust level of a route should be determined by the
  BGPsec protocol, local routing preference and policy MUST then
  be applied to best path and other routing decisions.  Such
  mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt].
 ...
3.17  If a BGPsec design makes use of a security infrastructure, that
  infrastructure SHOULD enable each network operator to select
  the entities it will trust when authenticating data in the
  security infrastructure.  See, for example,
  [I-D.ietf-sidr-ltamgmt].

 those references would seem to be obe.  dunno what to do with the first,
 drop it?  the second might ref lta-use-cases.

losing the last sentence in the first seems ok.
and the second moving to use-cases seems ok to me...

-chris

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] BGPSEC Algorithms document missing a clear reference?

[Christopher Morrow]

It was pointed out in passing (hallway/table conversation) that in:
  draft-ietf-sidr-bgpsec-algs-05 (at least 05)

there's this text in section 2:

NOTE: The exception to the above hashing algorithm is the use of

   SHA-1 [SHS] when CAs generate authority and subject key
   identifiers [ID.bgpsec-pki-profiles].

The reference to bgpsec-pki-profiles, is PROBABLY really:
   draft-sidr-bgpsec-pki-profiles
   http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol

There doesn't seem to be a reference to sha1 here for making an SKI.
It looks like you'd have to inherit and inherit from 3779 - 5280 and
text in section 4.2.1.2:
   For CA certificates, subject key identifiers SHOULD be derived from

   the public key or a method that generates unique values.  Two common
   methods for generating key identifiers from the public key are:

  (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
   value of the BIT STRING subjectPublicKey (excluding the tag,
   length, and number of unused bits).







Cooper, et al.  Standards Track[Page 28]


RFC 5280PKIX Certificate and CRL ProfileMay 2008


  (2) The keyIdentifier is composed of a four-bit type field with
   the value 0100 followed by the least significant 60 bits of
   the SHA-1 hash of the value of the BIT STRING
   subjectPublicKey (excluding the tag, length, and number of
   unused bits).


Is this the intention? that spelunking in rfcs is required to figure
out that sha1 would be used? or could/should the reference be more
clear?

-chris
(care of mystery caller #7)

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] [GROW] I-D Action: draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt

[Christopher Morrow]

On Fri, Nov 22, 2013 at 6:40 PM, Jakob Heitz jakob.he...@ericsson.com wrote:
 I think you mean paths with valleys are all instances of unintended routing.

 Surely, that can be fixed:
 A provider can reject valleyed routes from a customer BY DEFAULT,
 but allow some through if so configured.

 The point is that such a valley attribute can provide good information to 
 prevent
 the majority of route leaks without leaking customer relationship information.

is this a default-on property? or do I configure bgp-peer-A as 'i am a
customer' and peer-b as 'I am a transit'? what is the default expected
value? how do I verify that the value is correct? or do I just trust
the 3-as-hops away path I see? how is this better than today's:
filter your routes situation?

 -Original Message-
 From: Geoff Huston [mailto:g...@apnic.net]
 Sent: Friday, November 22, 2013 3:21 PM
 To: Jakob Heitz
 Cc: Christopher Morrow; g...@ietf.org g...@ietf.org
 Subject: Re: [GROW] I-D Action: 
 draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt

 If you are referring to the proposal that valley free paths are all 
 instances of unintended routing, then as I recall there is a line of 
 argument that says that some paths that contain valleys are intentional.


 On 23 Nov 2013, at 7:03 am, Jakob Heitz jakob.he...@ericsson.com wrote:

 Wasn't there once a proposal along the lines of:

 The originator adds a signed attribute that says this update is going up 
 the chain.
 Each AS signs it before passing it on.
 When an AS sends the update down the chain, it removes the attribute.
 When an AS receives an update clearly from below, it checks for the 
 presence of the attribute.

 What were the objections to this?

 --Jakob.

 -Original Message-
 From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Geoff Huston
 Sent: Friday, November 22, 2013 11:44 AM
 To: Christopher Morrow
 Cc: g...@ietf.org g...@ietf.org
 Subject: Re: [GROW] I-D Action:
 draft-ietf-grow-simple-leak-attack-bgpsec-no-help-03.txt


 On 23 Nov 2013, at 2:57 am, Christopher Morrow 
 christopher.mor...@gmail.com wrote:

 On Fri, Nov 22, 2013 at 4:47 AM, Geoff Huston g...@apnic.net wrote:

 On 22 Nov 2013, at 3:43 pm, Christopher Morrow 
 christopher.mor...@gmail.com wrote:

 On Thu, Nov 21, 2013 at 5:48 PM, Geoff Huston gih...@gmail.com wrote:
 but in our haste to comply with the timelines dictated by DHS's
 project funding I guess we've got what DHS were prepared to pay
 for, and not what we actually wanted or need. And for many its an
 unsatisfactory outcome.

 just asking about one part here... so DHS aside, because i'm not
 sure that who the funder is is relevant to the work, exactly...
 what options are there for securing more than the aspath?


 As I understand the draft correctly, the draft is saying even if you
 secure ASPATH along the lines proposed in secure BGP, there are
 still ways in which an attacker can inject a path that was not intended by 
 the originator.

 inject a path... hrm, I'm not parsing that properly I bet.

 Did you mean prepend on random asns? (no, don't think so, not and
 stay
 validated)
 Did you mean pull a route down a customer link and pass it back up
 the hill to the other transit? (sure, but that's known, right?)


 Chris, you have READ the draft I assume?


 So the question that the draft raises in my head is is it possible
 to communicate routing policies in a secure manner?

 so far this keeps coming up and keeps ending in a deathspiral of:
 People don't want to share their byzantine routing policy stuff 'publicly'

 or:
 sure, you could make a global registry of routing policy... isn't
 rpsl that? and it's working out how well so far?


 I hear different responses in other parts of the network, where communities 
 have invested significant levels of effort in publishing routing policies 
 and attempting to compute across them.

 It seems to me that ensuring that the protocol operates correctly does not 
 provide sufficient levels of assurance that a BGP speaker can reliably 
 distinguish between routing information that is in some sense genuine and 
 routing information that is intended to corrupt the speaker's forwarding 
 state.



 Additionally, the draft in question here still doesn't say how
 you'd know 'thats a route leak' more than 1 as-hop away form the 'leak'.
 (it also doesn't take into account any of the comments I provided
 to the authors :(  which is another matter entirely)

 so we get back to RPSL.

 maybe? though I'm not sure that it's any more helpful than just IRR
 based filtering with prefixes only and no policy-foo.

 I'm not sure its worth repeating the arguments that lead to the work in RPSL.

 Apparently, folk at the time who worked on RPSL held the belief that it was 
 more helpful.

 People have to
 be willing to be pretty damned specific in their policy language
 there.. Is 702 going to publish that they are a transit of NTT in
 Japan?


 good question - the folk in Japan seem to have been

Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice

[Christopher Morrow]

On Thu, Sep 26, 2013 at 5:19 PM, George, Wes wesley.geo...@twcable.com wrote:


 [WEG] close enough, ship it.

hurray! :) (I'm also ok with the last edit buffer fun)

thank wes and randy for a fun discussion.

-chris
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00

[Christopher Morrow]

On Wed, Sep 18, 2013 at 3:16 PM, Murphy, Sandra
sandra.mur...@parsons.com wrote:
 Looks like this is the final word.

 Consensus of the wglc is that the document is good to go, with revisions.

 Draft authors, could you please submit a new version with the wording 
 suggested below?


draft-authors: Y U NO SEND DRAFT UPDATE? :)

 As an update to RFC6487, this document broadens the class of certificates 
 that conform to the RPKI profile by explicitly including within the profile 
 those certificates that contain a policy qualifier as described here. A 
 relying party that performs a strict validation based on RFC6487 and fails to 
 support the updates described in this document, would incorrectly invalidate 
 RPKI objects that implement the changes in Section 2.

 Note this includes one nit change of implements to implement.

 Please also consider the nits mentioned in the message:
 http://www.ietf.org/mail-archive/web/sidr/current/msg06124.html

 --Sandy, speaking as wg co-chair


 
 From: Roque Gagliano (rogaglia) [rogag...@cisco.com]
 Sent: Monday, August 26, 2013 4:18 AM
 To: Geoff Huston; Murphy, Sandra
 Cc: Andy Newton; sidr@ietf.org list
 Subject: Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00

 Hi Geoff/Sandy,

 Agree that we can void the mention on the current status of the known RP. As 
 the due-diligence was done, I am fine.

 I think your proposed text  from Geoff goes well with the intention of the 
 original text (at least with the first sentence).It is just a matter of how 
 explicit we want to be in the consequences of not implementing the changes on 
 this document for RP parties. We and go with only his sentence or adding the 
 two sentences:

 As an update to RFC6487, this document broadens the class of certificates 
 that conform to the RPKI profile by explicitly including within the profile 
 those certificates that contain a policy qualifier as described here. A 
 relying party that performs a strict validation based on RFC6487 and fails to 
 support the updates described in this document, would incorrectly invalidate 
 RPKI objects that implements the changes in Section 2.

 Roque



 On Aug 24, 2013, at 12:03 AM, Geoff Huston g...@apnic.net wrote:

 Wouldn't it be better to note that: As an update to RFC6487, this document 
 broadens the class of certificates that conform to the RPKI profile by 
 explicitly including within the profile those certificates that contain a 
 policy qualifier as described here.

 Geoff



 On 24/08/2013, at 4:09 AM, Murphy, Sandra sandra.mur...@parsons.com 
 wrote:

 Speaking as working group chair:

 I can't be certain that this indicates a promise to modify the draft or 
 not.  Roque, Andy, could you comment?

 If so, a new version is needed and I'll say so on the list.
 If not, I'll have to ask for resolution on list.

 Speaking as regular ol' member (and a bit as wg chair, as I'm not clear 
 about the intent of the new text):

 I don't think this text hurts anything, but I am puzzled about the intent.  
 If all known implementations comply, why mention the problem?  OTOH, it 
 might serve to forestall AD/IESG questions.

 So I agree with Andy's observation, though I'd say a heading Backward 
 Compatibility Considerations rather than Interoperability Considerations 
 suits the situation better.

 (Apologies - searching for the thread, I found these comments stuck in my 
 draft folder from 17 July.)

 --Sandy

 P.S.

 strick-strict
 RPKI signed objects - RPKI objects because you mean CA certs as well 
 and signed objects might be taken to mean only ROAs and ghostbusters and 
 manifests etc
 implements-include or contain or...
 RP- relying party (or you'll have to define the acronym somewhere)
 Not sure what as in IDR means.

 
 From: Andy Newton [a...@arin.net]
 Sent: Tuesday, July 16, 2013 9:49 AM
 To: Roque Gagliano (rogaglia)
 Cc: Murphy, Sandra; sidr@ietf.org
 Subject: Re: [sidr] wglc draft-ietf-sidr-policy-qualifiers-00

 This sounds fine to me, though it is really an interoperability
 considerations section thingy. The IETF does those now, right? :)

 -andy

 On 7/16/13 4:55 AM, Roque Gagliano (rogaglia) rogag...@cisco.com wrote:

 Thanks Andy.

 Do you think we need to add something in the security section about the
 transition?

 Something like:

 A RP that performs a strick validation based on RFC6487 and fails to
 support the updates described in this document, would incorrectly
 invalidate RPKI signed objects that implements the changes in Section 2.
 At the time of this writing, all known RP software suites (you can
 mention them as in IDR) were tested and supported the updates on this
 document

 Roque

 On Jul 15, 2013, at 7:07 PM, Andy Newton a...@arin.net wrote:

 On 7/15/13 10:22 AM, Roque Gagliano (rogaglia) rogag...@cisco.com
 wrote:

 Before sending my support to advance to the IESG, I wanted to ask the
 author if they have tested the effects of 

Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice

[Christopher Morrow]

On Wed, Sep 25, 2013 at 12:38 PM, George, Wes wesley.geo...@twcable.com wrote:
 From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com]

 [CLM]
 In the RPKIcache example, 'consumer' is 'routers in your network'.
 'Close' is 'close enough that bootstrapping isn't a problem', balanced
 with 'gosh, maybe I don't want to put one on top of each router! plus
 associated management headaches to deal with these new
 systems/appliances'.

 [WEG] that's part of my issue - the only way that you get close enough that
 bootstrapping isn't a problem is when the cache and router are directly

there's some baseline that's acceptable, you intimate that IGP comes
up before EGP below. that makes some sense, and thus maybe the target
is 'in your igp, close enough that fiber failures won't be a problem'
then?

 connected. Otherwise there *is* going to be some amount of time while
 the router is coming up that it can't talk to its configured caches e.g. while

but the data in the cache only REALLY matters for bgp validation... so
your IGP clue below isn't unreasonable.

 it learns the route(s) to the cache(s). I think that supports a recommendation
 to put the caches in your IGP instead of BGP, so that you get faster

I actually didn't note a [ie]GP recommendation in the doc.

 convergence of those routes and therefore have access to the cache
 when BGP comes up and starts converging, rather than once BGP is
 partially converged. But the draft doesn't say that.

ok

 The question is, does the propagation/convergence delay for an IGP in an
 average network (let's call it somewhere between subsecond and 5 seconds)
 make a non-trival difference in RPKI's bootstrap behavior, especially since
 BGP convergence is also dependent on IGP convergence? Can we make a
 clearer recommendation of the performance envelope we're shooting for so
 that people can design accordingly? I'm not sure I buy a general faster(or
 closer) is always better recommendation - at some point, we hit diminishing
 returns, given that this is mostly a human time-scale system. The document
 doesn't provide clear guidance on how to balance that tradeoff.

i think a bunch of this really also depends on the operator deploying
though... 'its hard to get server people to do X for me' or 'gosh,
these appliances can be managed by network-operations! and they are
cheap-ish' or 'gosh, we don't have 1gbps ports anymore in general,
crap...'

I do think the original intent was to not dictate: Must be 5ms from
the router, or else!! and rely upon the operator to do the tradeoff
you just made above. Each network is different in it's expectations
from the infra, and each has different igp/egp designs as well as
fiber plant restrictions. I think it's going to be rough going making
a recommendation much more than:
  1) make sure the cache is available before BGP starts to converge for a device

and I actually can't come up with something else that's super helpful
:( even the above might be 'too much advice', if your plan is to
accept all routes and simply de-pref until validation might happen
then re-evaluate as you can.

 [CLM]
 I guess one way is to say: People should understand the dependencies
 and engineer appropriately ... which you kind of asked to not say in
 the original comment. (or is the issue that the dependencies aren't
 clear?)

 [WEG] The issue is that the dependencies aren't clear. I'm not expecting the
 text to be too prescriptive here, because all networks are different, but I 
 need
 enough technical discussion to properly understand the dependencies and
 engineer accordingly. This is an operational considerations document, so it
 needs to tell operators what breaks if they don't do it as recommended. If 
 this

ok...

 is about bootstrapping, then we need to be clearer about the relationship
 between bootstrapping and network convergence (since recommending
 that the cache is directly connected to the router is impractical) and how
 it impacts RPKI cache-router communication and performance. If it's about
 reducing latency via proximity, then we need to explain how much latency is
 too much latency and why. If it's about proper geographic diversity within a
 network's topology, then we need to say that. If we don't actually know if it
 makes a difference, and so are defaulting to recommendations that most folks
 agree are generally a good idea, we should say that. But right now we're
 assuming too much, IMO.

ok, the current text is:
   As RPKI-based origin validation relies on the availability of RPKI
   data, operators SHOULD locate caches close to routers that require
   these data and services.  'Close' is, of course, complex.  One should
   consider trust boundaries, routing bootstrap reachability, latency,
   etc

Maybe something like:
   As RPKI-based origin validation relies on the availability of RPKI
   data, operators SHOULD locate caches close enough to routers that
   require these data and services such that failures in local 

Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice

[Christopher Morrow]

On Tue, Sep 24, 2013 at 12:26 PM, George, Wes wesley.geo...@twcable.com wrote:
 From: Randy Bush [mailto:ra...@psg.com]
 i think the two paragraphs you would like to see improved are
 [snip]
 i am not against further explanation, send text. but short text.  :)
 [WEG] just the first paragraph really, and as I'll note below - I'd love to 
 send text, but I don't understand one of the recommendations

 experiments have shown that latency between cache and router, and
 between caches in a cache dag, is not an appreciable issue.
 [WEG] ok, so why is close important then?

 i thought bootstrap reachability would be fairly obvious to an operator.
 but if simple routing and no dns dependency were not obvious to you,
 then a few words are indeed needed.  or am i missing your point here?
 [WEG] yes, completely obvious. Though the last two sentences of your 
 suggested text in the other email is a useful addition


 what is missing from the second paragraph?
 [WEG] I'm actually happy with second para


 i am not sure it would be useful to go into the general issue of why
 caches should be proximal to the consumer as it is a rather well-
 explored area, from akamia and limelight to dns.  but if you have a
 sentence or two that communicates this, send it over.
 [WEG] Generally, I understand why closer is better for content caches 
 (Akamai/llnw) and DNS, but not for RPKI caches. You're making a link between 
 the two that I'm not following. Both of the

[CLM]
this is about the consumer of the data, right? (and convenience to the
operator that hosts the cache).

In the akamai/cdn example 'consumer' is 'cable/dsl/etc' user. Close
is convenient-to-the-operator close to the 'cable/dsl/etc' user.
Perhaps 'metro' is close enough for CDNs, balancing latency and
backhaul requirements.


In the RPKIcache example, 'consumer' is 'routers in your network'.
'Close' is 'close enough that bootstrapping isn't a problem', balanced
with 'gosh, maybe I don't want to put one on top of each router! plus
associated management headaches to deal with these new
systems/appliances'.

former benefit from proximity because it reduces latency and reduces
unnecessary backhaul and potentially allows for a geographically
customized service, resulting in improved user experience. If latency
isn't a factor (at least in the average-sized propagation domain), and
RPKI caches aren't particularly bandwidth intensive, why does
proximity matter? Is this just an extension of the trust domain and
limited dependence on routing protocols? If so, I'd dispense with
recommending close because it confuses the issue and just keep the
discussion about secondary dependencies and trust domains.

[CLM]
I guess one way is to say: People should understand the dependencies
and engineer appropriately ... which you kind of asked to not say in
the original comment. (or is the issue that the dependencies aren't
clear?)


 Thanks
 Wes George


 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.
 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Suspenders, redux

[Christopher Morrow]

great, thanks! I hope we can all have a read through prior to
vancouver and plan to discuss this there.

On Tue, Sep 10, 2013 at 7:23 AM, Stephen Kent k...@bbn.com wrote:
 Whoops. I forgot to include the URL for Suspenders:

 http://www.ietf.org/id/draft-kent-sidr-suspenders-00.txt
 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-06.txt

[Christopher Morrow]

On Fri, Sep 6, 2013 at 4:38 PM, Stephen Kent k...@bbn.com wrote:
 Dave,

 Fair questions for a somewhat complex environment.

 SIDR develops security standards for inter-domain routing, working within
 the context of
 BGP standards developed by IDR.

 GROW has more of an operations focus, and is intended to provide input to
 IDR.

 So, your doc on route leaks, if approved in GROW, could inform IDR about
 changes
 needed to BGP to counter this problem (which is not contrary to current BGP
 semantics). In turn, IDR could elect to revise BGP to address this problem,
 and
 then IDR could ask SIDR to develop security mechanisms to enable ASes to
 enforce the
 revised BGP specs, for example.

this does sound like the agreed upon plan ... yes.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] LTAM Discussion and questions

[Christopher Morrow]

On Thu, Aug 15, 2013 at 5:38 PM, Stephen Kent k...@bbn.com wrote:

 Chris,


 I agree with several of the folks who commented about the LTAMv2
 presentation and your call for comments.

 We need to provide an updated description of the problems we are trying to
 address, and details of how we propose to address these problems. The slide
 presentation at the meeting was intended to provide a preview, but it is not
 a substitute for detailed text.


ok... there seem to be several calls for 'please document what you mean to say'.

 So, let's begin the revised problem discussion, starting with text from the
 most recent version of the LTAM doc (v8). BTW, this text has not changed
 since the 00 version, dated November, 2010.

 The abstract from the I-D(s) says:

The primary motivation for the facility described in this

document is to enable an RP to ensure that INR information

that it has acquired via some trusted channel is not

overridden by the information acquired from the RPKI

repository system or by the putative TAs that the RP imports.

 This is still the primary motivation for LTAMv2, but I think it’s worth
 expanding on the rationale behind this mechanistic description of the
 motivation. The concerns we are addressing are twofold:

 -   Local use of private (RFC 1918) address space in conjunction with RPKI
 validation mechanisms

 -   Ways to recover from errors, or malicious actions, by CAs in the RPKI
 hierarchy



 In SIDR WG presentations we discussed the first rationale extensively. The
 second concern was discussed more extensively in RIR meetings, where the
 specter of law enforcement orders issued to RIRs was cited as a significant
 concern by some folks.



 As I mentioned in my presentation two weeks ago, we noticed that the
 mechanism that we documented was probably fine for dealing with allocations
 performed at the IANA and RIR tiers of the RPKI. So, for example, if an RP
 wants to employ RFC 1918 private address space with RPKI controls, the local
 TA mechanism, which makes use of “re-parenting” and “hole punching” would
 work. However, if we use these mechanism to protect address space for
 ISP-1, who received an allocation from ISP-2 (vs. from an RIR), problems
 could arise. Specifically, ROAs issued by ISP-2 could be rejected by an RP
 using LTAM, due to hole-punching. This was an unintended side-effect of the
 mechanism, one we would like to avoid.


this gets to some of the problem(s) that danny (and I think terry)
were concerned with... across administrative domains this all becomes
very dicey :( (or at least very undefined)

 The abstract also says:

This mechanism is designed for local use by an RP,
but any entity that is accorded administrative control over a

set of RPs may use this mechanism to convey its view of the

RPKI to RPs within its jurisdiction. The means by which this

latter use case is effected is outside the scope of this

document.



 The lack of a description of how to securely distribute the LTAM constraints
 file was viewed by some folks as a shortcoming. Moreover, we were approached
 by an NIR that wanted to extend the capability noted above. Their desire was
 to be able to publish resource allocation data for folks in their country,
 for consumption both internally and externally, in a way that would be
 immune to errors or malicious actions by actors within the RPKI hierarchy
 (but outside of their country). (This data needed to be valid as per the
 RPKI hierarchy, prior to any errors or malicious actions, to limit the
 ability of a country to make assertions about address space that was not
 allocated to entities within the country.)  No RPs outside of the country
 would have to pay attention to this data, but they could make use of it if
 they wished (if there were standards for how to make it available in a
 secure fashion). While an NIR raised this issue, the concern is generally
 applicable, irrespective of the presence of NIRs within a region.


sounds like 'crazy talk' (technical term), but sure.


 We revisited the LTAM design to see if we could address the cited
 motivation(s) via a mechanism that would not have the problem we noted
 above, and if we could also address the concerns raised by the NIR.  We also
 received some comments on the document noting that the mechanisms seemed
 complex, even after we revised the text to try to better explain what was
 happening. So, a simpler design was also a goal. Finally, we wanted to make
 the design a bit more flexible, to accommodate other objects that might be
 added to the RPKI system in the future.

ok... so at the end of the day you are going to spin a draft to talk
about this in more detail, or that's what it sounds like you're
planning on doing :) If there were a draft out in the next say 4 weeks
we could have a better discussion about this on-list and then a longer
(and probably more fun) talk at the next meeting in Vancouver? Is 4wks
doable for 

Re: [sidr] Princeton University:: Impacting IP Address Reachability via RPKI Manipulations

[Christopher Morrow]

On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent k...@bbn.com wrote:

 Danny,

 The architecture permits overlapping allocations to accommodate transfers
 that involve address space that
 is in use. I've been told by several operators that, for this sort of
 transfer, such overlap
 is required.


overlap with respect to:
  ADDRESSBLOCK + ASN

right? so initially:
  128.2.35.0/24 + AS28

In the near-future as 128.2.35.0/24 moves from AS28 - AS4:
  128.2.35.0/24 + AS28
  128.2.35.0/24 + AS4

and at some point in the further future:
  128.2.35.0/24 + AS4

(and ideally the initial ROA ends up on a CRL...)

right? Enable /make before break/ for customers moving from attachment
point to attachment point.

-chris


 Steve
 On 4/2/13 12:02 PM, Danny McPherson wrote:

 ...

 As for today, the architecture permits such collisions, which I think is
 the issue most agree is, err.. suboptimal.

 -danny

 __**_
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/**listinfo/sidrhttps://www.ietf.org/mailman/listinfo/sidr


 __**_
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/**listinfo/sidrhttps://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] comments on the repository analysis I-D

[Christopher Morrow]

On Thu, Mar 21, 2013 at 6:09 AM, Oleg Muravskiy o...@ripe.net wrote:
 Hi Christopher,

 Christopher Morrow wrote:
 Comment 1 (also related with 44): I agree that ISPs may operate caches in 
 behalf end-users ASNs, but also I think that more than 1
 cache may be operated by a single ISP. Imagine a global ASN operator with 
 routers in several places. Are they going to have just
 one master cache? Or are they have one or two (backup), and just in one 
 location? Considering this, even the 40k clients may be
 low as worse case IMHO.
 oops, so... we need to be clear in terminology here there are at least:
   o publication points - places/machines AS Operators would make their
 authoritative information available to the world.

 In our analysis we associate number of CAs in the global RPKI with the number 
 of distinct IP resource holders.


sure, and as a proxy for that 'AS Operator', it's not a 1:1
correlation to be sure but it should be reasonably close, no?

 You seem to associate publication points (that directly relate to CAs) with 
 AS Operators.
 Since it's a second place where publication points are associated with AS 
 Operators (another is the RPKI rsync Download Delay
 Modeling presentation), I wonder if I miss something?

most likely you are not... I think I jump to 'CA == REPO ==
AS-Operator == ASN allocated' because lacking any direct data
otherwise it seems like a good estimation of numbers. Essentially each
ASN allocated is going to be a repository that needs to be gathered,
right? If there are 10% more repositories due to EndSite allocations
without an ASN also allocated to them I think it's still in the
ballpark to say number of Repos == ASN allocation number.

I could be wrong.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] comments on the repository analysis I-D

[Christopher Morrow]

On Thu, Mar 21, 2013 at 11:43 AM, Randy Bush ra...@psg.com wrote:
 In our analysis we associate number of CAs in the global RPKI with
 the number of distinct IP resource holders.
 sure, and as a proxy for that 'AS Operator', it's not a 1:1
 correlation to be sure but it should be reasonably close, no?

 do we have anything other than conjecture on which to base estimations
 of the numbers of CAs or repositories?

no, since there aren't any CA's in existence... we have, or I have, a
model that says:
  If you want to publish a ROA, you need to have a CA and you need to
run a publication point

To me that means at the least every ASN will have a publication point
(and this a roa and a CA).

 I jump to 'CA == REPO == AS-Operator == ASN allocated' because lacking
 any direct data otherwise it seems like a good estimation of numbers.

 great example of conjecture.  do you have any fact/measurement-based
 idea of how many CAs or repositories there might be five or ten years
 from now?  the only data i have is the small number of IRR repositories
 and whois servers.  and i suspect/hope that is a poor estimator.

I really don't know how to estimate ASIDE from saying: it seems
reasonable that the repo number will track with assigned ASN

I could be wrong, I could also be corrected if someone else has a
compelling story... I don't think it's harmful to say tracks to ASN
numbers though, if it's too large a number we can be surprised by
performance... if it's too small, we can also be surprised :)

 but i very strongly doubt that any significant portion of the stub ASs,
 84% of the ASs, will run CAs.

they may not.
they may use a hosted-model product.
I suspect that very soon after 'hosted model' comes into being in the
large, the operators of these systems will realize that if someone
dislikes one of their customers they can't survive as a business if
all other customers also disappear. They will be forced to run the
system with unique names/ips for each customer (names at a minimum so
they can shift problem children away).

So, in the above case... CA == ASN == REPO

-chris
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] comments on the repository analysis I-D

[Christopher Morrow]

On Thu, Mar 21, 2013 at 1:55 PM, Randy Bush ra...@psg.com wrote:
 I have, a model that says:
  If you want to publish a ROA, you need to have a CA and you need to
run a publication point
land this a roa and a CA).

 Wherever did you get that?

I figured in the worst case you'd end up with 1:1... I don't think
it'll be much worse than 1:1, it could be better, of course.

 what is the ratio of hosted LIRs to delegated today?

not sure... I believe that hosted == delegated though in the long run,
from the perspective of what ip/name you have to connect to in order
to access the data stored in the repositories.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] comments on the repository analysis I-D

[Christopher Morrow]

On Thu, Mar 21, 2013 at 4:42 PM, Danny McPherson da...@tcb.net wrote:
 On 2013-03-21 14:29, Chris Morrow wrote:

 TODAY it reduces the number, yes. 100% agree.
 TOMORROW the number of repositories, even those which are 'hosted' will
 be split up by name and/or ip-address...

 I have a feeling these will be like DNS servers and likely ripe (ha!)
 points for attack by bad folks. So sharing fate for all customers just
 seems like a bad idea.

 folks become unhappy with the repository management, but for now I think
 it is reasonable to assume a much smaller number of repositories, which
 is what Sriram and I did in our model.


 yup. but having the ability to increase the number of repositories in
 the model means we can say: today with N repositories and M objects we
 see times of Y. Tomorrow when we have X repositories with Y objects we
 should see times of Z


 Agreed.

 Additionally, this perspective may well change when things like BGPSEC
 router keys need to be published and then ingested by operational routers
 for update signing, as the trust model is fairly different, methinks.

so, to me, this is just 'more objects with a tight(er) timeframe on
delivery' right?

meaning: today you have (for sake of the conversation) relatively
static content in the repository, where data changes 1/2/3
objects/day, and it's important to get the data distributed, but
(again, for the conversation) 24hrs is 'fine' as a timeline between:
publish object and rendered onto the router.

but: tomorrow if you followed (for the sake of the conversation)
Sriram's model of 'roll router keys hourly to ensure ttls on routes'
(loosely paraphrased and with times I don't even think he put into his
slides/discussions), you'd be talking about #-of-routers * 24 objects
changing every day, and with a timescale for: publish to render on
the order of 1hr. (likely less than 1hr, something closer to 5-10
minutes has been discussed previously).

right?

-chris
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] comments on the repository analysis I-D

[Christopher Morrow]

On Thu, Mar 21, 2013 at 5:42 PM, Danny McPherson da...@tcb.net wrote:

 so, to me, this is just 'more objects with a tight(er) timeframe on
 delivery' right?

 meaning: today you have (for sake of the conversation) relatively
 static content in the repository, where data changes 1/2/3
 objects/day, and it's important to get the data distributed, but
 (again, for the conversation) 24hrs is 'fine' as a timeline between:
 publish object and rendered onto the router.

 but: tomorrow if you followed (for the sake of the conversation)
 Sriram's model of 'roll router keys hourly to ensure ttls on routes'
 (loosely paraphrased and with times I don't even think he put into his
 slides/discussions), you'd be talking about #-of-routers * 24 objects
 changing every day, and with a timescale for: publish to render on
 the order of 1hr. (likely less than 1hr, something closer to 5-10
 minutes has been discussed previously).

 right?


 Yeah, I think so under steady state.

 It gets more interesting when the RIR is attacked and I can't reach them, or
 I have a failure of a control card or systems where I cache them locally, or
 something to that effect.

 AND I have to know when *everyone* else in the system picks them up and
 pushes them out to their routers in preparation for validation so that I
 know when it's safe to starting signing with them, etc..

true, but the repository conversation stops at: all gatherers in the
system have the data

inside each ASN it's really up to the ASN operator to get from
gatherer - cache - router in a 'timely fashion'.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] comments on the repository analysis I-D

[Christopher Morrow]

I'm not a fan of word in general.. but this comment numbering rules ;)

On Mon, Mar 18, 2013 at 10:33 AM, Arturo Servin arturo.ser...@gmail.com wrote:
 Hi,

 Some comments about Steve comments:

 Comment 1 (also related with 44): I agree that ISPs may operate caches
 in behalf end-users ASNs, but also I think that more than 1 cache may be
 operated by a single ISP. Imagine a global ASN operator with routers in
 several places. Are they going to have just one master cache? Or are
 they have one or two (backup), and just in one location? Considering
 this, even the 40k clients may be low as worse case IMHO.

oops, so... we need to be clear in terminology here there are at least:
  o publication points - places/machines AS Operators would make their
authoritative information available to the world.
  o 'gatherer' machines - machines an AS Operator would use to gather
repository data from all of the publication points.
  o caches - systems inside of and AS which provide the digested data
to the routers of that operator's network.

Note that:
  1) a publication point may share common hardware/network/etc with
another publication point (shared/hosted model)
  2) a AS Operator may operate more than one 'gatherer' perhaps they
partition the publication space ? or some other strategy is in use
(local decisions not really relevant, I think, for overall discussion)
  3) a cache may be only internal facing all for me, only! or it may
provide the cache services for external parties (customers,
random-joe-internet-operator, researchers).
  4) it's entirely up to the AS operator to decide how many and in
what configuration the caches are in his/her network.

I think that most of Tim/Oleg's doc is about publication points and
the load placed on the entire system by gatherers... I don't think
they tackle the cache part at all in their doc.

As to the end of the comment in question:
 So, I don’t think this
parameter is a good estimate (worst case, but
probably not representative). 

I think it's fair to state: The worst case today is AS's == Gatherers
which is the intent of tim/oleg's work here... I think :)

I think another part of Stephen's comment is really that there's the
potential for an AS operator to run a gatherer for his/her customer's
to benefit from... That doesn't seem unreasonable, but it's not
knowable how many WILL do that, so I'd err on the side of worst-case
and jump to #AS == #gatherers. (as long as that's stated clearly)

As to the memory limits imposed by platforms chosen for the study,
it's probably fair to not that any system which drives toward
max-memory+ is going to hit a cliff in performance when the system is
forced to swap :( try to avoid swap... it's slow (so I hear).

 Comment 10: Not sure if I understand the point, but because we do not
 trust fully on BIND we also operate DNS with NSD. In fact, I agree with
 the authors that we have a problem depending on just one implementation
 of rsync.

 Comment 28: For LACNIC ~ 2,500 members and ~ 2,200 PI. But as opposite
 to RIPE NCC, PI holders are members as well (not sure if this is
 relevant to the numbers)

 Comment 31: I do not have numbers of prefixes per ROA, but it is a
 number that we could get soon.

 Comment 44: Does any body has a pointer of that proposal?

I suspect this is actually a comment about cache's not gatherers?
Either way I'm not sure a 2x factor matters in end here...

 Comment 46: This is hard to answer. I have heard some operators asking
 for minutes to have fresh new ROAs. Some others do not mind and request
 objects every few hours. What is the middle or agreed value? (also
 related with 55)

this, I think, is from some of the discussions Danny/Eric have been
driving about time to get CRL updates out everywhere, or times to get
a new ROA published and seen 'everywhere'. I believe we ended up
talking about a time of on the order of 2-5 minutes for: Have new
prefix, make roa, get published and distributed

I don't know that that number matters a LOT today, it will certainly
be much more interesting as a target in a few more years (when
deployment is further along).

 Comment 57: I think the reason is that CDNs today work on http and we
 know them more or less well. Although possible it would be more
 expensive and complex to have rsync-CDNs. Also this is related to

'rsync cdn' == 'lots of rsync servers' really, right? since really you
are essentially making new 'cache' (at the cdn) for each client... the
only think you're winning with this approach (and rsync) is moving the
tcp endpoint closer (maybe) to your client/requestor.

Has anyone (not to derail too far) thought about git or another
network-based RCS system for this? It seems that (as much as I was
poking the tiger on the IETF thread about this) the checkpointing and
such is attractive... done right, it'd even give the history data that
some folks want for the changes to objects.

 comment 54, the single point is magically distributed by the CDN

for 

Re: [sidr] comments on the repository analysis I-D

[Christopher Morrow]

On Mon, Mar 18, 2013 at 12:22 PM, Bryan Weber brweb...@yahoo.com wrote:
 Anyway, as someone who has considered this in the past I just wanted to
 document some of my thoughts regarding the idea.

awesome, thanks! I didn't imagine one monolithic repository, but one
per pub-point.. I don't think conflicts exist if you simple sync
always from each repository... well, the conflicts seem simpler to get
out of: master always wins.

In the end though, I was just imagining :) I'm not wedded to the idea/concept.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] ORIGINs

[Christopher Morrow]

On Tue, Mar 12, 2013 at 9:38 AM, Matthew Lepinski
mlepinski.i...@gmail.com wrote:
 A quick clarification: The current BGPSEC protocol specification can easily
 be modified to protect the ORIGIN attribute. (That is, prevent it from being
 modified by intermediate ASes.)

 I can very quickly put out an update to the BGPSEC protocol specification if
 the working group decides that there is a requirement to protect the ORIGIN
 attribute.

I wonder if it's worth protecting it as an option?
In other words protect origin at the origin's discretion.

 It is valuable to have this discussion. I am personally sceptical of
 preventing the modification of the ORIGIN attribute. However, if others in

it seems like there are thorns to watch out for, for sure... and
mandatory action will certainly have us falling into the thorns minus
protection.

 the writhing group see value in protecting the ORIGIN attribute, then I want

autocorrect or freudian slip? :)

 to know about it. (And it is certainly the case that I understand the issue
 better now than I did before this discussion started.)

 -Matt Lepinski

 On Mar 11, 2013 11:34 PM, Danny McPherson da...@tcb.net wrote:

 On 2013-03-11 13:31, Stephen Kent wrote:

 Danny,

  We have been told by several operators that the values stated in
 Section 4.3 of RFC 4271 are not what is used today. We also have been
 told that, contrary to the SHOULD NOT in Section 5.1.1 of this RFC,
 it is not uncommon for ASes to change this value, en route. Given
 these two observations, I don't see how one can argue that protecting
 this attribute via a PATHSEC mechanism makes sense.


 84% of ASes are stubs, apparently.  Many of our own ASes are stubs and we
 buy transit services in some places from some of the ISPs that like to muck
 with the ORIGIN code to exploit traffic attraction attacks. I'd like a
 secure routing protocol to be derived from requirements that accommodate
 issues that both ISPs and stub ASes are concerned with.  That's what I'd
 like as an operator. If this is yet another thing that you believe is beyond
 the scope of SIDR because the current BGPSEC spec doesn't accommodate it
 then why don't we stop pretending to be writing threats and requirements
 documents and you just publish your BGPSEC spec?

  Separately, there is the issue of whether it makes sense to address
 the security of the ORIGIN attribute in the threats document. The SIDR
 charter states that the path security goal is Is the AS-Path
 represented in the route the same as the path through which the NLRI
 traveled


 Careful, I'm not sure the current BGPSEC spec does that at all for the
 AS_PATH, and it actually diverges in some places.  If you're going to use
 the charter again to nix this requirement as an acceptable residual
 vulnerability in the threats draft then it's crystal clear to me that you
 and the BGPSEC design team simply want to publish the BGPSEC draft as you've
 already envisioned and you don't want to accommodate my operational
 requirements.  If that's the case then let's just kill the threats and
 requirements documents and save everyone's time.

 There are a variety of other attributes that do not directly
 support this goal, and which are not being addressed as part of the
 PATHSEC model.


 Right, and I think they should be, as they all impact BGP path selection
 in various ways.

 The threats document already addresses this issue, in
 the Residual Vulnerabilities section.


 Out of curiosity, does anyone intend to ever address the growing list of
 residual vulnerabilities or is this merely a place to catalog requirements
 that would rather not be addressed?

 I suggest the following updated
 text for that section, to better explain the criteria for inclusion
 and exclusion in that document:

 PATHSEC is not planned to protect all attributes associated with an
 AS_PATH, even though some of these attributes may be employed as
 inputs to routing decisions. Thus attacks that modify (or strip) these
 other attributes are not prevented/detected by PATHSEC. The SIDR
 charter calls for protecting only the info needed to verify that a
 received route traversed the ASes enumerated in the AS_PATH, and that
 the NLRI in the route is what was advertised. (The AS_PATH data also
 may have traversed ASes within a confederation that are not
 represented. However, these ASes are not externally visible, and thus
 do not influence route selection, so their omission in this context is
 not a security concern.) Thus, protection of other attributes is
 outside the scope of the charter, at the time this document was
 prepared.


 Again, I'd like some clarity on how long we're going to hide behind an
 explicitly worded charter, or if we're actually going to address any of
 these issues?

 -danny

 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr


 ___
 sidr mailing list
 sidr@ietf.org
 

Re: [sidr] ORIGINs

[Christopher Morrow]

On Sun, Mar 10, 2013 at 12:00 PM, Danny McPherson da...@tcb.net wrote:
 On 2013-03-08 11:10, Murphy, Sandra wrote:

 In reviewing the discussions about the threat document, the wg
 eventual consensus wrt one topic was not clear to the chairs.

 The ORIGIN attribute was mentioned by some as having the potential to
 be used out-of-spec to influence routing through the neighbor (and
 their neighbors, etc.).

 One response was that there is no way to verify the authenticity of
 the ORIGIN's original value, so the origin AS could mis-use this
 attribute no matter what we do.


 The origin AS sets the value of the attribute to whatever THEY desire -- the
 concern was that upstream ASes can manipulate this to launch traffic
 attraction attacks.  This happens today with some of our transit providers,
 and we'd like the option to be able to mitigate that attack if we're going
 to put a bunch of stuff in place to secure inter-domain routing on the
 Internet.


 Also, a later discussion pointed out that the original need for the
 ORIGN attribute had long since been OBE,


 Many origin ASes set the value to various upstreams intentionally today to
 impact path selection in upstream ASes, so it is very much in use today,
 even if not for the originally envisaged application.


 but that ISPs had re-purposed
 the attribute for influencing traffic.  Several operators mentioned
 that ISPs find it useful to modify this attribute and spoke against
 protecting the integrity (ie preventing the modification).


 Right, that want to be able to exploit traffic attraction attack vectors,
 whereas, as an origin AS I'd like to have the capability to prevent that.


 The current draft does not mention the ORIGIN attribute as a threat.

 Is that the right outcome?


 No.


 That is, was the desired outcome:

 (1)  yes, we know it is a threat but we know we can't  don't want to
 protect it, so might as well leave it out.   (current state). why do
 make-work.


 It's not make-work, it is a clear threat - you say yourself in the question.
 It needs to be reflected in the threats draft and accommodated in subsequent
 requirements and solutions work.  We should not keep it out of the threat
 draft simply because the solution does not currently accommodate it (we've
 done lots of that already).


 (2)  we should mention it as a threat but then mention the bits about
 can't authenticate the original value and don't want to protect the
 integrity (ie want to permit modification).


 It's a threat, we don't need to have a solution here, we're talking about
 the threats draft.  It should lead to a requirement and then the solution
 can be developed.


 If there's no interest in changing, the threats draft stands as it is
 on this point.


 How many times do I need to defend this operational feedback before it's
 considered and accommodate in the threats draft?

I think the question was a survey sort of question: 'Should this be in
the threats doc? Is the intent to come back and say: Yes, origin
changes along the path for many reasons, we want to protect against
this. (ie: origin changes are a threat) OR Yes, origin changes along
the path, we actually want to keep this feature available.'

There were at least 2 people talking about origin, one from either
side I think... so clarification would be good.

 -danny



 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] slight whoops ...

[Christopher Morrow]

On Thu, Mar 7, 2013 at 3:25 PM, Danny McPherson da...@tcb.net wrote:
 On 2013-03-07 13:18, Christopher Morrow wrote:


 please click on this link to accept my TOS:
   https://badplace.com/malwareCPS.cps.doc.exe.pdf.gif


 That could be included anywhere - and if it's in a resource certificate then
 you've got far bigger problems than a malware attack, methinks.

agreed, there's also dns pinning and a host of other ways.

 Heck, this might well serve as an early indicator of compromise, if we
 really believe this is a legitimate issue.

 It also applies to ANY publication mechanism in any protocol, so I think
 it's rather a bit of a reach.  Of course, I look forward to text from
 malware attacks in all IETF documents going forward, and this one
 specifically..  :-)

yea, it'll be fun! :)

-chris

 -danny

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013)

[Christopher Morrow]

On Mon, Mar 4, 2013 at 6:56 PM, Sean Turner turn...@ieca.com wrote:
 I guess I should have also said that I support moving this draft down the
 path towards publication.


I got that :) I am/was/am waiting for the next rev to pop into the tracker.

 spt


 On 3/4/13 6:40 PM, Terry Manderson wrote:

 I'll go along with that.

 I'm not seeing any major structural alterations to the draft (at this
 stage) by doing that.

 Cheers,
 Terry

 On 02/03/2013, at 2:37 AM, Christopher Morrow morrowc.li...@gmail.com
 wrote:

 Great... so assuming the authors deal with this set of comments we'll
 ask them to spin a new version and submit that for WGLC when it
 arrives?

 Does that seem like a good path for those still listening?

 -chris
 co-chair-1-of-3

 On Thu, Feb 28, 2013 at 9:30 AM, Sean Turner turn...@ieca.com wrote:

 Below are some comments on the draft.  I also submitted my nits to the
 editors.

 0) Based on the assumption that draft-newton-sidr-policy-qualifiers will
 be
 adopted because that's what the RIRs want should s1.2 or 1.5 also
 include
 some information about where it can be found?  This information would be
 identical to the URI included in the policy qualifier?

 1) s1.6: CP - Is it worth nothing that there might be another CP for the
 BPKI?

 2) s4.6.1: Not sure if this needs to go here but don't we need to say
 something about not renewing certificates forever?

 3) draft-ietf-sidr-rtr-keying describes the procedures for operator
 generated keys (i.e., those that are not router generated).  A couple of
 questions come to mind:

 a) Should the CPS point to that draft in s6.1.2 or will the CPS be
 updated
 when draft-ietf-sidr-rtr-keying is published?

 b) draft-ietf-sidr-rtr-keying allows operators sign the private keys
 they
 generate and subsequently send back to the router.  Should this be
 explicitly called out in s4.5.1.  For s.4.5.2, is the returned
 signed-key an
 RPKI-Signed Object?

 spt


 On 2/21/13 11:30 PM, Chris Morrow wrote:


 WG folks,
 As the subject states, let's please start a WGLC poll for the document:
 draft-ietf-sidr-cps-01
 http://tools.ietf.org/html/draft-ietf-sidr-cps-01

 with the abstract:
This document contains a template to be used for creating a
 Certification Practice Statement (CPS) for an Organization that is
 part of the Resource Public Key Infrastructure (RPKI), e.g., a
 resource allocation registry or an ISP.

 So far the authors have made a few revisions, with updates based on
 comments/feedback, at this time the document has been stable for more
 than 6 months time, let's move this along if there are no further
 issues/addendums/questions/appendixes.

 thanks!
 -chris
 co-chair-1-of-3
 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr

 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr

 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr



___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013)

[Christopher Morrow]

Great... so assuming the authors deal with this set of comments we'll
ask them to spin a new version and submit that for WGLC when it
arrives?

Does that seem like a good path for those still listening?

-chris
co-chair-1-of-3

On Thu, Feb 28, 2013 at 9:30 AM, Sean Turner turn...@ieca.com wrote:
 Below are some comments on the draft.  I also submitted my nits to the
 editors.

 0) Based on the assumption that draft-newton-sidr-policy-qualifiers will be
 adopted because that's what the RIRs want should s1.2 or 1.5 also include
 some information about where it can be found?  This information would be
 identical to the URI included in the policy qualifier?

 1) s1.6: CP - Is it worth nothing that there might be another CP for the
 BPKI?

 2) s4.6.1: Not sure if this needs to go here but don't we need to say
 something about not renewing certificates forever?

 3) draft-ietf-sidr-rtr-keying describes the procedures for operator
 generated keys (i.e., those that are not router generated).  A couple of
 questions come to mind:

 a) Should the CPS point to that draft in s6.1.2 or will the CPS be updated
 when draft-ietf-sidr-rtr-keying is published?

 b) draft-ietf-sidr-rtr-keying allows operators sign the private keys they
 generate and subsequently send back to the router.  Should this be
 explicitly called out in s4.5.1.  For s.4.5.2, is the returned signed-key an
 RPKI-Signed Object?

 spt


 On 2/21/13 11:30 PM, Chris Morrow wrote:

 WG folks,
 As the subject states, let's please start a WGLC poll for the document:
 draft-ietf-sidr-cps-01
 http://tools.ietf.org/html/draft-ietf-sidr-cps-01

 with the abstract:
This document contains a template to be used for creating a
 Certification Practice Statement (CPS) for an Organization that is
 part of the Resource Public Key Infrastructure (RPKI), e.g., a
 resource allocation registry or an ISP.

 So far the authors have made a few revisions, with updates based on
 comments/feedback, at this time the document has been stable for more
 than 6 months time, let's move this along if there are no further
 issues/addendums/questions/appendixes.

 thanks!
 -chris
 co-chair-1-of-3
 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr

 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-04.txt

[Christopher Morrow]

On Tue, Jan 22, 2013 at 10:07 AM, Eric Osterweil
eosterw...@verisign.com wrote:
snip
 - I also don't understand how the text in this (a threats document) can claim 
 that route
 leaks are beyond the scope of PATHSEC in a fait accompli manner...  This is a
 threats document, right?  This is a threat to BGP, right?  The RPKI provides
 semantics that

is the 'leak' a threat to 'BGP' or to the users of the network?

``BGP, itself does not include semantics...'' for... I don't think applying 
this exclusion to
 route leaks survives a sniff test.

the RPKI is simply a database, it's not part of the BGP protocol. The
RPKI system doesn't include bgp peering data, so while you could
detect and potentially mitigate a 'hijack', it's not clear to me that
you'd know 'leak' vs 'new peering arrangement' just based on the RPKI
data.

 Overall, I think the threats document is still missing a badly needed 
 treatise on route
 leaks.

is it fair to say that you would like the threats document to say, in
perhaps more words than this:
  BGP Path Security has no capability to influence or inform the bgp
system of 'route leaks'.

this, I think, does run afoul of stephen's want for a definition of
'route leak' though... but I think it's what you're aiming at?
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

[sidr] Fwd: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-00.txt

[Christopher Morrow]

of interest ... sounds like (from the abstract) this is more along the
lines of a BCP.


-- Forwarded message --
From:  internet-dra...@ietf.org
Date: Fri, Jan 18, 2013 at 9:48 AM
Subject: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-00.txt
To: i-d-annou...@ietf.org
Cc: op...@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Operational Security Capabilities
for IP Network Infrastructure Working Group of the IETF.

Title   : BGP operations and security
Author(s)   : Jerome Durand
  Ivan Pepelnjak
  Gert Doering
Filename: draft-ietf-opsec-bgp-security-00.txt
Pages   : 24
Date: 2013-01-18

Abstract:
   BGP (Border Gateway Protocol) is the protocol almost exclusively used
   in the Internet to exchange routing information between network
   domains.  Due to this central nature, it's important to understand
   the security measures that can and should be deployed to prevent
   accidental or intentional routing disturbances.

   This document describes measures to protect the BGP sessions itself
   (like TTL, MD5, control plane filtering) and to better control the
   flow of routing information, using prefix filtering and
   automatization of prefix filters, max-prefix filtering, AS path
   filtering, route flap dampening and BGP community scrubbing.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OPSEC mailing list
op...@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] I-D ACTION:draft-ietf-sidr-cps-00.txt

[Christopher Morrow]

Hey there SIDR folk,
 This draft seemed to expire, yesterday, oops! I think we need a CPS
describing document, so I bet the authors will refresh this in time.
That said:
  1) does the current version need work still? Was the combination of
the previous 2 documents:
   http://tools.ietf.org/html/draft-ietf-sidr-cps-irs
   http://tools.ietf.org/html/draft-ietf-sidr-cps-isp
a good thing to do? (it seems to remove some page flipping and
combine what was mostly the same content anyway into one reference)
  2) if this is 'ok' as is, should we send out a wglc now/soon for
this document?

-chris
(co-chair 1 of 3)

On Tue, Jul 10, 2012 at 12:08 PM,  internet-dra...@ietf.org wrote:
 A new Internet-Draft is available from the on-line Internet-Drafts 
 directories.
 This draft is a work item of the Secure Inter-Domain Routing Working Group of 
 the IETF.

 Title : Template for a Certification Practice Statement (CPS) for 
 the Resource PKI (RPKI)
 Author(s) : S. Kent, et al
 Filename  : draft-ietf-sidr-cps
 Pages : 42
 Date  : July 10, 2012

   This document contains a template to be used for creating a
Certification Practice Statement (CPS) for an Organization that is
part of the Resource Public Key Infrastructure (RPKI), e.g., a
resource allocation registry or an ISP.

 A URL for this Internet-Draft is:
 http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-00.txt

 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/

 Below is the data which will enable a MIME compliant mail reader
 implementation to automatically retrieve the ASCII version of the
 Internet-Draft.


 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] the need for speed

[Christopher Morrow]

On Wed, Dec 26, 2012 at 12:37 PM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:

 However, I would note that the use case I've outlined above is more broad 
 than 'just' DDoS attack.  Specifically, think of natural or man-made 
 disasters.  In the latter case, it's often the case that a customer's 
 primary DataCenter is taken offline and, although they [may] have a 
 secondary/backup DataCenter, they hadn't adequately provisioned capacity 
 into it.  In those cases, the answer is, generally, to bypass the undersized 
 physical equipment/tail-circuit/whatever in order to restore service as 
 quickly as possible.  In the example diagram I've highlighted above, this 
 could involve removing an undersized CE router from the physical path 
 between my PE and their server farm, (because it's physical interfaces, 
 processing power, whatever are not adequately sized).


 Would it be possible to leave the BGP session intact from their CE to your PE?
 If not, can a new BGP session (possibly over a TCP session that may go over 
 multiple physical hops if necessary) be set up between your PE and the 
 customer? Customer could even use a simple PC emulating a BGP router to do 
 this. Then they can originate their own prefix and directly pass the 
 announcement to your PE; the update could be unsigned (when there is 
 origin-only validation) or signed in the future (when there is path 
 validation).



I don't know that solving the many examples with many different
solutions one at a time is helping here... In general:
  1) there are cases where some relationship exists before the
'event', whatever that event may be
  2) there are cases where no relationship exists before the 'event'.

In both cases there are a myriad of solutions in place today, some of
which will be complicated in a more 'bgpsec' world (or a more RPKI
world). Making the potential new world be as nimble as the old seems
to be what Shane/Danny are aiming for, right? Ratholing on the 12 sins
of christmas doesn't seem helpful to the overall goal.

-chris
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] the need for speed

[Christopher Morrow]

On Wed, Dec 19, 2012 at 12:33 PM, Pradosh Mohapatra (pmohapat)
pmoha...@cisco.com wrote:
 In these use cases, what breaks if we allow two ROAs to co-exist in the
 system (one authorizing the customer AS and one authorizing the proxy AS

the system already permits multiple ROA's for the same prefix, right?

 to originate the prefix) _much before_ the attack (or storm) takes place?
 After all, this is a valid business relationship. Choose your pill wisely.

the concern, for the dos-mitigation and really for the flashcrowds as
well (same thing in the end, Oops, server go boom, move service to
more-servers-r-us!), is the lack of prior relationship and thus lack
of existence of a new ROA.

-chris
(course, I could have missed your question entirely)
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] the need for speed

[Christopher Morrow]

On Wed, Dec 19, 2012 at 1:54 PM, Pradosh Mohapatra (pmohapat)
pmoha...@cisco.com wrote:
 No, thanks for clarifying. For DDoS mitigation at least, I thought there
 would be a prior business relationship. I am not familiar with on-the-fly
 relationship building process.

for that case, and shane's (and probably a few more) the 'new
relationship' could exist for:
  1) a short period of time
  2) immediately upon close of a phone call

so, some extra churn in the rpki system as well as routing-system data
changes. I think one of the points to haggle about is 'how quick' do
they need to happen.
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] the need for speed

[Christopher Morrow]

On Tue, Dec 18, 2012 at 4:24 PM, Dongting Yu dongting...@cl.cam.ac.uk wrote:
 [apologies if I am sending this multiple times, having trouble with replying]

 A concept that could be borrowed from DNS side is the ability for
 anyone to go from the top and skip the cache(s) on an ad hoc basis.

stop... no.

The architecture as laid out is, from 'roa creator' to 'roa consumer', roughly:
  A publication point (nominally one per roa-creator)
  B gatherers (nominally one per roa-consumer)
  C internal-cache-systems (some number per roa-consumer)
  D routers

(yes, there is the iana-rir part of the tree
 yes, there are are more than just ROAs in the repositories)

So, the part that Randy and Danny and Eric are talking about is, as
far as the global system, is the A - B conversation. Once you get
beyond B (to C and D) the problem is entirely inside some operator's
network and nothing on the outside matters.

Essentially the problem here is distribution of 10k of data to ~40k
endpoints (today, it'll grow tomorrow, fine) in ~2 mins time (or 5
mins or 10 mins or ... someone draw a line in the sand so we know what
the target is)

 Perhaps we need a similar capability here, for anyone to query from
 the top. This way, a new announcement can (for example) carry a flag
 that says this may look invalid but if you skip the cache you will
 see that it is, and suggests the receiving party to validate it from
 the top.

at the router? no, don't do that.


 Of course, two things will soon follow: some will always ask others to
 skip the cache, which would defeat the purpose of caching (but I would

once you have QOS, everything is EF!

 argue that it is not hard to figure out who are wasting others'
 bandwidth and cpu, by comparing the non-cached versions as requested
 and the cached versions), and this mechanism itself can be used to
 launch a DDoS (to which I would argue the RIRs already has enough
 resources to handle it, or some tricks can be perhaps applied to make

do they?

 this problem less significant in the first place).

 Dongting
 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system

[Christopher Morrow]

On Fri, Dec 7, 2012 at 12:35 PM, Montgomery, Douglas do...@nist.gov wrote:

 suggesting/discussing loading a RIB from DNS queries.   I was thought we
 were discussing information systems that might allow me to validate the
 origin of an router's RIB.   That problem is O(500K) at time zero.

backing up a bit in the thread, and I hope/think setting some things
up a bit better for the conversation... or attempting to :)

If we look at the whole system (or a bunch of it) in SIDR/BGPSEC/RPKI,
there are likely these moving parts:

  o RPKI repositories (some number, let's say 1/ASN for simple numbers)
  o RPKI TAL/TA/'Root' bits (say 5 today, hopefully 1 tomorrow which then
lets you walk down the tree to find all the actors)
  o network operators running networks (again 1/ASN)
  o gathering hosts/systems at each of the above would talk to all
repositories and
 gather the content for local use/distribution (again 1/ASN at
least, probably safe
 to assume 2/ASN at least)
  o cache systems inside each ASN, more than 1, less than 1/router seems sane?

In the end, the last item is completely up to the AS operator in
question. They may choose to run 1 cache/router, or one for their ASN,
they are responsible (according to the docs) to keep their cache's
semi-coherent, or as close to coherent as they can.

So, looking at timing information there's a base time for: Make a
ROA/EE/etc change to the local repository, that timing is almost up
to the local operator, then things beyond that are about automatic...
first gatherers get data, then local-caches will get sync'd and
distribute to the routers the updates required. It's important to note
that a smart solution would only pass updates to the caches, or rather
the caches would update from some point-in-time that the gatherers
kept. (again, this is likely dependent upon the local operator's
timing requirements/design).

One point that's brought up a bunch on the thread so far is 'cold
start'. There are many forms of this:
  o for a router
  o for a cache
  o for a gatherer
  o for an ASN
I think for some the answer is 'easy', and the timings are 'fast'. For
others though the timing is longer.

For instance, a router cold-start (presuming no special knob request) is:
  1) boot
  2) load-os/config
  3) prefer internal/igp
  4) load cache-data
  5) bring up bgp (e and i) sessions
(it's probably harder to determine if 3 and/or 5 happen before 4
today, but that seems like a vendor tweak to me)
Loading the cache data should be essentially lan-speed limited... or
at least limited by the cache deployment that the operator picks.

A gatherer cold-start is: Fetch all objects from all remote
repositories and is likely bounded by times calculated in eric's
paper... or similar. 1/asn links with X average time to
connect/download/digest...

An ASN cold-start is ... actually pretty simple, except that they rely
upon everyone else finding them, so they are likely bounded on start
by the time it takes all remote-asns to walk the system and find them
(call it 4hrs based on the timings in the ops-docs?).

I think the discussion so far has centered around 'all' of the system,
but has variously talked about only 1-2 parts (really) when it comes
to timings. Could we think about the problem-space and timings in the
above framework? or alter the above to something we can all agree
upon?

-Chris
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system

[Christopher Morrow]

On Fri, Dec 7, 2012 at 1:24 PM, Russ White ru...@riw.us wrote:

   You are twisting the fact when you are mixing hosted-rpiki and
 rpki-repositories as the same thing.

(*note quoting russ's message, but not actually aiming at russ in particular)

could we focus a bit of the conversation on the issues of scaling and
timing and not on this one particular bit of the puzzle which is
optional anyway? (hosted repositories) I don't think it helps to focus
on 'to host or not' since really the problem of timing is not about
where the repository is (as much, corner cases aside) as that there is
a repository.

thanks!
-chris
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Reboot: questions regarding WG acceptance of draft-ymbk-rpki-grandparenting-02

[Christopher Morrow]

clarifying question in your example...

On Fri, Dec 7, 2012 at 12:32 PM, Brian Dickson
brian.peter.dick...@gmail.com wrote:
 P.S. Here is a worked example to illustrate this concept:

 Suppose the initial state of affairs is as follows:
 10.0.0.0/8 is delegated by IANA to RIR A. RIR A does not route any
 portion of this block, but only doles out portions of it.
 10.1.0.0/16 is delegated by RIR A to LIR A1. Again, not routed.
 10.1.0.0/20 is delegated by LIR A1 to ISP B. ISP B routes this prefix.
 10.1.15.0/24 is delegated by ISP B to customer C. C routes this prefix,
 which is more-specific and preferred over 10.1.0.0/20.

 Now add to the above, that ISP B goes out of business.

 The proposed way of directly assigning the 10.1.15.0/24 to C would be to
 have the delegation done directly to C by RIR A, or by LIR A1.
 (Or by IANA, only included for completeness, i.e. this would likely never
 happen.)

 And, in order to continue to assure the uniqueness of the assignment, the
 corresponding delegations would need to explicitly call out the
 NON-delegation of 10.1.15.0/24, attached to the delegation chain starting
 wherever the fork occurred.

you mean a CRL would be updated with the previous certificate for 10.1.15.0/24 ?
So, you are essentially saying:
Grandparenting == re-delegation + break-old-delegation-cert ? (seems
ok to me...)

 So, if the direct delegation is done by LIR A1, the new delegations by A1
 would be:
 10.1.0.0/20 minus 10.1.15.0/24 (from LIR A1 to ISP B (which is defunct,
 presumably, but whose assets might be sold to another party))
 10.1.15.0/24 (to C directly)

 Or if the direct delegation is done by RIR A, the delegations would be:
 10.1.0.0/16 minus 10.1.15.0/24 (from RIR A to LIR A1)
 10.1.15.0/24 (from RIR A to end-user C)
 10.1.0.0/20 minus 10.1.15.0/24 (from LIR A1 to ISP B)

 The minus foo would need to be attached to any delegation covering foo,
 throughout the delegation hierarchy, once such a fork occurs.
 ROA validation would need to check this, but the logic is quite simple.

or just adhere to the crl, right?

 On Fri, Dec 7, 2012 at 11:54 AM, Alexey Melnikov alexey.melni...@isode.com
 wrote:

 Hi,
 Sorry for procrastinating on this for so long.

 Here are questions I would like to ask WG participants. At this point I
 would like to ask people to review the questions and let me know if you
 think they are contradictory. If they are clear, I will poll the WG early
 next week. Comments on the mailing list or sent directly to WG chairs
 sidr-cha...@tools.ietf.org are welcome.

 

 1) Is the problem described/solved by draft-ymbk-rpki-grandparenting-02
 actually a problem that the WG needs to address? (Answer: yes or no.
 Additional information is welcomed, but I don't want people to repeat the
 whole discussion.)

 2) If you answered yes to the question #1, please also answer the
 following question:

 Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to become
 a WG document? Please choose one of the following:


 a) Ready for Adoption (whether or not you have some specific issues with
 it. Also, this answer is unrelated to whether this should be a separate
 draft or a part of an existing draft).

 b) Needs more work BEFORE Adoption

 c) Should not be adopted. In particular this mean that you don't believe
 any amount of work on the proposed draft will address your issues. So any
 solution to this problem should be a new draft written from scratch.

 d) Abstain/don't care


 3) If you answered a or b above, please also answer the following
 question:

 Does this need to be in a standalone draft, or can it be incorporated into
 another existing WG draft? When answering this question please only base
 your answer on technical reasons, in particular please leave the decision on
 who is going to edit the document (if it is standalone) to WG chairs.


 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr



 ___
 sidr mailing list
 sidr@ietf.org
 https://www.ietf.org/mailman/listinfo/sidr

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr