Dear Joel, > since this is on the agenda I'd thought I'd add some comments
And indeed thanks for that! First I see that you probably worked on a wrong version of the doc as we are now on draft-ietf-opsec-bgp-security-01 > section-4 worth noting citing/rfc 6192 > > Protecting the Router Control Plane We have section 3 for protection of the router itself where we are referencing RFC6192. I find it clearer to leave reference in section 3. > section 5.1.2.3 > > these sections are too deep. needs better organization, e.g. section 5 > is actually probably two or three sessions. > > e.g. > > 5.1.1. Prefixes that MUST not be routed by definition > > Most of Regional > Internet Registries do also operate an IRR and can control that > registered routes conform to allocations made. > > 3 of 5 Changed to "A majority of Regional Internet Registries […]" > should cite > > http://tools.ietf.org/html/rfc4012 > > rpsl It's cited I believe: "5.1.2.3. Prefix filters creation from Internet Routing Registries (IRR) An Internet Routing Registry (IRR) is a database containing internet routing information, described using Routing Policy Specification Language objects [16]" > would be helpful to cite irrtoolset provide an example in an appendix. That's interesting. I put that on a TODO list. I'll see what we can do. > the tier one example isn't that helpful would be more interesting to > cite the example for a customer vantge point e.g. managing objects so > that your upstreams will accept them. Yes I heard the point in the meetecho recordings. I believe you were the one who made that point? I may not agree with the fact the example is a tier one example. We have many small ISPs peering everywhere on the Internet. Some do not even connect any customer (just servers) and they want there content to be accessible over the Internet. These guys may be interested in making sure they accept appropriate routes coming from each of the peers. I wrote that section with these guys into consideration. I was also thinking of other transit networks (not tier 1) connecting directly customers that I used to operate. These guys are far from being tier 1 (2 steps away) but still they peer, sometimes with the aforementionned CDNs. Still I understand that this section is maybe not clear on applicability (ie who should do what?) and indeed we have not talked much about objects and what people SHOULD do. Point taken, I'll see what we can do. > ---- > > rpki section needs to be fleshed out e.g. what you do with it, how it's > used what it can't be used for needs examples. > > The rest of this > section assumes the reader understands all technologies associated > with SIDR. > > Whut??????? This was removed. I received several interesting comments on this section and there is an existing operational doc so we will change few things yes. > > 5.1.4 > > mixes customer prefixes filtering policy with local prefixes… Good point. I'll try to improve this. > issues around loop-detection (e.g. disconnected islands) vs more > specific(s) e.g. hijacking. > > outbound filtering (prefix advertisement) Not sure what you mean with this point? Still referering to 5.1.4? > 5.3 and later > > prefer to think of these things as import/export policy rather than > describing everything as filter. OK. Will see how to deal easily with this. > 8. > > o Do not accept overly long AS path prepending from the customer. > > going to have to scope that. New text is "try to discourage excessive prepending in such paths". I'm afraid it's difficult to scope that is an IETF document (or we should think of some standard). Thanks, Jerome -- Jerome Durand Consulting Systems Engineer - Routing & Switching [email protected] - +33 6 35 11 60 50 http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr CISCO France 11, rue Camille Desmoulins 92782 Issy les Moulineaux CEDEX 9 FRANCE _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
