On Wed, Nov 16, 2011 at 12:35 AM, Christopher Morrow <[email protected]> wrote: > On Wed, Nov 16, 2011 at 12:29 AM, Brian Dickson >> Does this illustrate the importance of not only validating origins, >> but also only using signed prefixes if you are participating in >> BGPsec? > > sure, but if your customer forgets to pay a bill, calls you up and > (post proper 'this is the customer' authentication) says: "Hey, srsly, > I forgot, checks in the mail to ARIN, can you accept our route pls?"
I was using "only" in contrast to Jakob, who was suggesting having the same prefix and as-path, both signed and unsigned, be used, and in fact the unsigned used prior to validating the signatures. Basically, if you have BGPsec enabled with a given peer, you might get a combination of signed and unsigned from that peer - but for a given prefix, you MUST only get one or the other. Invalid-sig != unsigned. Accepting unsigned as a "fast" short-cut is insane, frankly. Signed prefix processing actually needs to "block" until the signature result is received. On a per-prefix basis, of course. This is why having your cache very close is important, as are any possible implementation optimizations or design considerations that improve signature processing/capacity/timeliness. > you may be willing to do same, you may also be willing to do this in > the case of internal services routes that you don't actually want > externally visible. Sure - and locally significant signatures/trust-anchors are very important for just such an occasion. (For any convenient value of "local", it should be noted. City, zip code, province, continent, building, whatever.) > > re-announcement is 'harder' since it's not clear if NTT is supposed to > be passing cogent aol's routes or not, is it? Agreed - I can't be specific on exactly when, but expect me to present something "real soon now" on a nuts-and-bolts level of how to do this. Maybe a month, maybe two. Brian _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
