Re: [sidr] request for agenda items for interim meeting 6 Jun
well, actually, the discussion in april was walking around many of the implications thereof. it is hard to discuss do we keep/replace AS[4]_PATH as it is abstract and draws deep philosophical discourse with no hard handles on technical decision points. I think you should remove the [4] from the discussion. 4 bytes ASN is mandatory for BGPSEC speakers. So, there should be no AS4_PATH attributes between BGPSEC routers to keep/replace. i agree. but every time i say AS_PATH someone whacks me with AS4_PATH. maybe this is why i like the NO_EXPLICIT_PATH :) randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] request for agenda items for interim meeting 6 Jun
i agree. but every time i say AS_PATH someone whacks me with AS4_PATH. maybe this is why i like the NO_EXPLICIT_PATH :) well, you are normally consistent at asking people to read the documents :-). r. randy smime.p7s Description: S/MIME cryptographic signature ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] request for agenda items for interim meeting 6 Jun
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Randy Bush Sent: Wednesday, May 23, 2012 6:09 PM To: Murphy, Sandra Cc: sidr@ietf.org Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun In the interim in San Diego, there were requests (from operators) that guidance to operators of how to provision a router with the needed keys would be a good idea. We had some discussion in the Paris meeting of two drafts discussing provisioning the routers with their needed private keys. There's also been a recent flurry of discussion on the list. no comments on the new version of draft-ietf-sidr-rtr-keying-00.txt. would appreciate some now or we can ask for wglc. [WEG] We're again having an interim collocated with NANOG, ostensibly to gain additional operator participation (as well as batch travel). However, in order to gain any benefit from the location, we probably need to publicize the interim on the NANOG list, though the window for doing it before travel plans are made is probably closing/closed. Wasn't it on the NANOG agenda in SD? It's not this time... It may even be useful to have a set of questions to fire off in a lightning talk regarding the things we plan to discuss in more detail over the course of the interim, so that people who have opinions on the matters can weigh in. 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
Re: [sidr] sidrSlides for RPKI Over BitTorrent presentation
heasley h...@shrubbery.net writes: This sure smells to me like a solution in need of multicast (or, more accurately, deployed multicast) with a fall back to something like bittorrent for bootstrapping or when you've missed session data and can't recover. Multicast as a data stream would be much more efficient is collecting updates, although there are still issues that would need to be worked through like how do you know you heard everything. Oh, and it only works if you multicast deployed to your site of course. please, we do not want multicast as the only solution. does your noc know how to debug multicast forwarding problems? I didn't say only :-) . In fact, I pointed at bittorrent as a backup. I simply said it would be more efficient when sending out *new* changes. -- Wes Hardaker SPARTA, Inc. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] sidrSlides for RPKI Over BitTorrent presentation
Thu, May 24, 2012 at 06:36:51AM -0700, Wes Hardaker: I didn't say only :-) . In fact, I pointed at bittorrent as a backup. I simply said it would be more efficient when sending out *new* changes. understood; i'm registering/re-enforcing that if that is developed it must not be the only mathod. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
[sidr] [INTERIM MEETING 6/6] Agenda update
The 6/6/2012 (6/6/2012 for the EU folks or Jun 6 2012) meeting agenda looks like: * aspath not present - implications? - scudder's notes at previous meeting perhaps not all the bugs worked out/considerations made (not just tools, re-figuring the aspath on entrance/exit, are there other places where aspath is used/required? confeds is one example?) - rbush's noted method to deal with this in confeds * rekeying processes/procedures/implications - two drafts (roque + randy) one focused on router side key management (onboarding/etc) one focused on overall key change process (including rpki/routers/etc) * performance measurement bounds - andree/tim's interest in this publication point sizing and operations/sla requirements - what parts of the system get metric'd and why are those important? - sriram - sizing requirements for routers in defined roles in the network. Note that we have only ~5hrs for the meeting so we may have to stack-rank the above into the items we really WANT to get through first. also, this is available (and will be updated at): http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120606 -chris (co-chair 1 of 3) [0]: wiki - http://trac.tools.ietf.org/wg/sidr/trac/wiki/WikiStart ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] request for agenda items for interim meeting 6 Jun
On Thu, May 24, 2012 at 9:19 AM, George, Wes wesley.geo...@twcable.com wrote: However, in order to gain any benefit from the location, we probably need to publicize the interim on the NANOG list, though the window for doing it before travel plans are made is probably closing/closed. Wasn't it on the NANOG agenda in SD? It's not this time... I sent a note to the nanog list... hopefully folk will be able to attend either physically or virtually. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] sidrSlides for RPKI Over BitTorrent presentation
heasley h...@shrubbery.net writes: Thu, May 24, 2012 at 06:36:51AM -0700, Wes Hardaker: I didn't say only :-) . In fact, I pointed at bittorrent as a backup. I simply said it would be more efficient when sending out *new* changes. understood; i'm registering/re-enforcing that if that is developed it must not be the only mathod. Agreed. If we can't do it over carrier pigeon, we have no real backup. -- Wes Hardaker SPARTA, Inc. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] [INTERIM MEETING 6/6] Agenda update
An astute reader notes that the original message: http://www.ietf.org/mail-archive/web/sidr/current/msg04563.html (additionally, until a moment ago the wiki doc for the meeting had this text copied/pasted into it...) Had the original timing data (full-day), the space and other constraints dictate that the meeting will actually be 1300-1800 PDT. -chris On Thu, May 24, 2012 at 1:15 PM, Chris Morrow morr...@ops-netman.net wrote: The 6/6/2012 (6/6/2012 for the EU folks or Jun 6 2012) meeting agenda looks like: * aspath not present - implications? - scudder's notes at previous meeting perhaps not all the bugs worked out/considerations made (not just tools, re-figuring the aspath on entrance/exit, are there other places where aspath is used/required? confeds is one example?) - rbush's noted method to deal with this in confeds * rekeying processes/procedures/implications - two drafts (roque + randy) one focused on router side key management (onboarding/etc) one focused on overall key change process (including rpki/routers/etc) * performance measurement bounds - andree/tim's interest in this publication point sizing and operations/sla requirements - what parts of the system get metric'd and why are those important? - sriram - sizing requirements for routers in defined roles in the network. Note that we have only ~5hrs for the meeting so we may have to stack-rank the above into the items we really WANT to get through first. also, this is available (and will be updated at): http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120606 -chris (co-chair 1 of 3) [0]: wiki - http://trac.tools.ietf.org/wg/sidr/trac/wiki/WikiStart ___ 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] sidrSlides for RPKI Over BitTorrent presentation
Wes, On May 23, 2012, at 9:22 PM, Wes Hardaker wrote: Bittorrent works well for sharing the load, but either requires a lot of bittorrent start files (whatever they're called), which then becomes hard to syncronize; or a small number of bittorrent files (one per aggregation point) that indicate you need to refetch and entire .zip file even if you already have most of it anyway. I'm far from an expert on Bittorrent but I believe this is not right. A .torrent file (what you called a bittorrent start file) can contain contain a list of files to be transferred, there's no mandate to zip them into a single file first. Presumably the BT protocol is smart about not transferring files you already have locally -- that's kind of the whole point. Rob's operational overview slide makes it clear he's imagining operating in the collection-of-files mode. Probably there are some issues with this mode of operation too -- if you list every single RPKI object individually then the size of the .torrent file scales linearly in the size of the unauthenticated/ tree. This seems likely to suck since I am guessing BT's normal operating regime is to transfer small numbers of large files rather than potentially vast numbers of relatively tiny files. The zip files Rob's slides talk about just contain the .torrent file and manifest (which is also O(N) in the size of the tree, sigh). Speaking purely as a Bittorrent amateur + not the author of the slides! --John ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] sidrSlides for RPKI Over BitTorrent presentation
On Thu, May 24, 2012 at 4:13 PM, John G. Scudder j...@juniper.net wrote: Wes, On May 23, 2012, at 9:22 PM, Wes Hardaker wrote: Bittorrent works well for sharing the load, but either requires a lot of bittorrent start files (whatever they're called), which then becomes hard to syncronize; or a small number of bittorrent files (one per aggregation point) that indicate you need to refetch and entire .zip file even if you already have most of it anyway. I'm far from an expert on Bittorrent but I believe this is not right. A .torrent file (what you called a bittorrent start file) can contain contain a list of files to be transferred, there's no mandate to zip them into a single file first. Presumably the BT protocol is smart about not transferring files you already have locally -- that's kind of the whole point. Rob's operational overview slide makes it clear he's imagining operating in the collection-of-files mode. per publication-point I think? So you have to collect N-thousand of these torrent files, and keep N-thousand torrent jobs running and keep state on N-thousand remote torrent files changing over time... some of this could be alleviated in many ways, worst case though is that. Probably there are some issues with this mode of operation too -- if you list every single RPKI object individually then the size of the .torrent file scales linearly in the size of the unauthenticated/ tree. This seems likely to suck since I am guessing BT's normal operating regime is to transfer small numbers of large files rather than potentially vast numbers of relatively tiny files. well, folk like fedora/ubuntu/etc offer full distributions over bittorrent ... I've not done a find . | wc -l on a system like this in a long time, but 4-8 gb over bittorrent for a few thousands of files seems to work fairly well for them. The zip files Rob's slides talk about just contain the .torrent file and manifest (which is also O(N) in the size of the tree, sigh). maybe looking at a bittorrent-like solution for intra-as distribution is interesting though? though that also seems (to me) to fall into 'local implementation' land, from the vendor/arms-dealer that sold me the solution. Speaking purely as a Bittorrent amateur + not the author of the slides! me too, as an amateur of bittorrentz I mean. -chris --John ___ 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] [INTERIM MEETING 6/6] Agenda update
* aspath not present - implications? - scudder's notes at previous meeting perhaps not all the bugs worked out/considerations made (not just tools, re-figuring the aspath on entrance/exit, are there other places where aspath is used/required? confeds is one example?) - rbush's noted method to deal with this in confeds i am not sure i would clump all of this under aspath, but what the heck. can we please add shane's aliasing issue and hopefully this time we can make it clear in the minutes? also, the pfx-validate authors are currently polling eachother to ask for wglc on that doc, and it may be worth putting on the agenda so folk at the meeting can whack us appropriately. also, new revs of origin-ops and bgpsec-ops are out. folk may wish to comment. on all those docs, i do not think a 'presentation' is warranted. if folk have not read them, that is their problem and does not warrant the comic book edition being presented to waste the time of those who have done their homework. of course, presentations to clarify important and complex issues would be useful, if there are such. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
[sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.txt
The authors have stated that they believe that draft-ietf-sidr-rpsl-sig-05 Securing RPSL Objects with RPKI Signatures is ready for a working group last call. The draft can be accessed at http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-05 and https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ This announces the beginning of the wglc. The last call will end on Friday, 08 Jun 2012. Please judge whether you believe that this work is ready for publication and send any comments to the list. --Sandy, speaking as wg co-chair ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] [INTERIM MEETING 6/6] Agenda update
On Thu, May 24, 2012 at 7:05 PM, Randy Bush ra...@psg.com wrote: * aspath not present - implications? - scudder's notes at previous meeting perhaps not all the bugs worked out/considerations made (not just tools, re-figuring the aspath on entrance/exit, are there other places where aspath is used/required? confeds is one example?) - rbush's noted method to deal with this in confeds i am not sure i would clump all of this under aspath, but what the heck. can we please add shane's aliasing issue and hopefully this time we can make it clear in the minutes? sure thing, your name is there purely for placeholder... with the example that you thought you'd already worked through properly on-list + in-room. also, the pfx-validate authors are currently polling eachother to ask for wglc on that doc, and it may be worth putting on the agenda so folk at the meeting can whack us appropriately. sure, keep in mind we have only 5 hrs. also, new revs of origin-ops and bgpsec-ops are out. folk may wish to comment. list comments seem great for that, at least for starters. on all those docs, i do not think a 'presentation' is warranted. if folk have not read them, that is their problem and does not warrant the comic book edition being presented to waste the time of those who have done their homework. of course, presentations to clarify important and complex issues would be useful, if there are such. sure. 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] WGLC for draft-ietf-sidr-rpsl-sig-05.txt
a quick read only. and sorry to wait for wglc, but that's life. at least i did not wait for ietf lc :) -- what is RPSL? it is not defined, nor is there a cite. -- 2.1. General Attributes, Meta Information in general, the format/syntax of the attribute part of many fields might be specified more precisely. have mercy on the people who are gonna write code to parse this stuff. e.g. time is expressed as the decimal representation of an unsigned integer, but what is a decimal representation? ascii? (note that 3.1.4 does this) i'd even settle for examples. the list of attribute names needs to cite the enumeration of allowed names, kinda hard if RPSL has no cite. blah blah blah. -- 2.1. General Attributes, Meta Information 2. Reference to the certificate corresponding to the private key used to sign this object (field c). This is a URL of type rsync or http(s) that points to a specific resource certificate in an RPKI repository. needs a cite -- 2.1. General Attributes, Meta Information 3. Signature method (field m): what hash and signature algorithms were used to create the signature. The allowed algorithms which can be used for the signature are specified in [RFC6485]. sec folk, is this sufficiently specified that i can get a sure parse? i am three levels deep in rfcs and am still not sure. -- 2.1. General Attributes, Meta Information 5. The signed attributes (field a). This is a list of attribute names, separated by an ASCII + character (if more than one attribute is enumerated). The list must include any attribute at most once. as rfc 2622 has many attributes which are multi-valued, which of the set is being signed? -- Optional fields of the signature attribute: is it a field or an attribute? both are used. decide. -- One applications for such a mechanism include the case of a route[6] object, where both the prefix owner's and the AS owner's signature is expected (if they are different parties). first, this is an example of why a mild grammar pass is needed. second, the trust model of the rpki ROA is that the AS owner does not attest. i do not remember the trust model in RPSL and am too lazy to try to figure it out as it cites 2725 which says 3. Routes should only be announced with the consent of the holder of the origin AS number of the announcement and with the consent of the holder of the address space. but i just do not have the energy to find how this is stated, validated, ... in this way too looong doc. but the difference in trust models could be at least noted. and i have this nagging worry that there is trouble waiting in that list of urls of certs. the references and referents are not necessarily stable and the resulting instability of a collection of them could be interesting. -- 2.2. Signed Attributes One can look at an RPSL object as an (ordered) set of attributes uh, i guess one could. but my memory is that the are not strictly ordered. you may want to say if and why ordering is actually important to this draft. -- 2.2. Signed Attributes trust model issue. what attributes may [not] be signed by, for example, a prefix cert? may prefix certs [not] sign different fields/attributes than AS certs? -- The type of the object determines the minimum set of attributes that MUST be signed. The signer MAY choose to sign additional attributes, in order to provide integrity protection for those attributes too. forward ref to sec 4 would be helpful here. is integrity the only assertion being made if for signed attributes beyond the minimum set? with multiple signers, is, for example, the AS holder signing an route: object really attesting to the holes: and org:? -- why not mandate the canonic syntax of 3.1.4 in the objects themselves? -- 3.2. Signature Creation 3. Arrange the selected attributes according to the selection sequence specified in the a field as above, omiting all attributes that will not be signed. attributes which may be repeated are gonna be fun. -- back to tex randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.txt
These are my comments on the draft draft-ietf-sidr-rpsl-sig-05 In the Introduction (Para 3) it says: A maintainer of such signed database objects MUST possess a relevant resource certificate which shows him/her as the legitimate holder of an Internet number resource I'm afraid I'm confused on how you make the jump to saying a maintainer of RPSL objects has a resource certificate which lists the resources 'shows him/her as the legitimate holder.' There is no identity information in the resource certificate. Further (and in the Abstract) says are done by the legitimate holder(s) of the internet resources. I think this is misaligned. Many legitimate resource holders (that aren't in the ISP game) outsource their routing 'stuff' and would probably palm off the creation of resource certs to someone else who might then hold the private key - so I would argue that the more correct approach here, is to say that: modifications of such database objects are authorized by the holder(s) of the private key for the resource certificate that encompasses the the Internet resources mentioned in those objects. The second last sentence clarifies somewhat, but my point is that I don't see that the maintainer::Resource Holder::Private Key Holder is a simple straight line. (and I note that the mntner object has no additional handling, so in a way the mntner and the private key and resource cert in the 'signature:' attribute can be quite unrelated except for some IRR process to assert some relationship, somehow. Is/was there any discussion on why the mntner asserts no awareness of a signature or relevant published rescerts that may come into play over the objects it is responsible for?) Section 2.1, The new attribute signature looks to update RPSL (RFC2622) shouldn't a 'updates' in the RFC header? section 2.2, nit. Allowing the maintainer an object to select the attributes that are covered by the digital signature achieves the goals established in Section 1. missing of, should be: Allowing the maintainer of an object to select the attributes that are covered by the digital signature achieves the goals established in Section 1. In Signature Creation (3.2) I would like to see a pointer to section 4. You have gone to the effort to provide a sensible list of the attributes in RPSL objects to sign over (which I like!), might as well highlight this to the reader in section 3 and also in the intro and abstract. For me this is an important piece. I think the security considerations section needs work. Your rightly point out that confidentiality (as a public object) is not a concern. I would like the integrity of the RPSL object reworded so that you are actually talking about the attributes (section 4) of the RPSL object which are signed over. There are no words about availability. I think it needs to be highlighted that signing the objects still does not guarantee any level availability or end to end integrity. It's whois. :-) Any object can be modified in transit (MiTM) to drop the signature attribute and modify the RPSL contents should an attacker wish to. Can you provide a set of actual examples in an appendix? I am most interested in seeing an example with the optional references to other parties certificates field 'o'. and additional signatures. (section 2.1, second number '2' bullet) For the most part I have no strong objections to this document moving forward. Cheers Terry On 25/05/12 9:06 AM, Murphy, Sandra sandra.mur...@sparta.com wrote: The authors have stated that they believe that draft-ietf-sidr-rpsl-sig-05 Securing RPSL Objects with RPKI Signatures is ready for a working group last call. The draft can be accessed at http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-05 and https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ This announces the beginning of the wglc. The last call will end on Friday, 08 Jun 2012. Please judge whether you believe that this work is ready for publication and send any comments to the list. --Sandy, speaking as wg co-chair ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr smime.p7s Description: S/MIME cryptographic signature ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
