Re: [sidr] request for agenda items for interim meeting 6 Jun

["John G. Scudder" <[e-mail]>]

[added IDR to cc]

On May 30, 2012, at 12:10 PM, Murphy, Sandra wrote:

...
> About extensibility - as you say, any new segment type not built into implementations would result in fatal errors.  So any new segment type would need to be built into implementations before use.  The question then becomes - can the signature attributes also be augmented at the same time to deal with the new segment types?
...
> So the AS_PATH extensibility could be maintained in the security protections - as long as the new extension is "protectable".

OK, as long as it's practical to extend the BGPSEC_Path_Signatures attribute. I confess to not having given this much thought but it doesn't appear to be as easily extensible as AS_PATH, because the latter has a TLV structure and the former doesn't. I guess your answer is that since AS_PATH extensions are in practice a big deal, you'll just introduce a new, incompatible format of BGPSEC_Path_Signatures to match? If this is the plan, BGPSEC_Path_Signatures should include a version number, since it would be a little rude to consume another code point from the one-byte BGP path attribute code point space for this purpose. Also, for generality you'll need to think about whether you want to be able to support different subsets of extensions -- this is easy in a TLV-encoded attribute but hard if all you've got is a version number. (Another answer might be that Additional_info will serve as the extensibility placeholder, but if so its length field is too small.)

...
> I am quite sure I don't know the complete list of AS_PATH knobs!

Nor do I, from memory. But we probably should plan to enumerate a list of them so that we can categorize them as "we can do this", "this is formally an attack and therefore will never be supported", or "other", and then iterate on "other".

> But some of those I do know are hacks that would allow attacks as well.  The fact that the security protections prohibit the attacks is a good thing.  If there's a way to identify good, not evil, uses, then we can design for that.  But in cases where there's no real way to distinguish the good from the evil, we're in a hard place.  Shoot a hole in the protection to allow the hack or prohibit the hack.

Right, and agreed (see "formally an attack" above). But to repeat my further point, if the AS_PATH is present (even if not secured): "at least there's scope for a network operator on the receiving end to tolerate the validation failure and use the route anyway, if desired. In the case where there's no AS_PATH, the data are just gone with no chance for appeal."

--John