A few small comments. On Mon, Jul 27, 2015 at 04:33:59PM +0200, John G. Scudder wrote: > This document defines a mechanism to obtain a full dump or provide > continuous monitoring of a BGP speaker's local BGP table, including
Delete "local" as I believe it implies Loc-Rib. Perhaps make "BGP routes" instead of "BGP table". [...] > Implementations of this protocol MUST require manual configuration of > the monitored and monitoring devices. I suggest SHOULD. This MUST will eventually get us into "trouble" when someone decides that this sort of thing should be auto-provisioned as part of some networking infra, potentially using other protocol hints. > Unless a transport that provides mutual authentication is used, an > attacker could masquerade as the monitored router and trick a > monitoring station into accepting false information, or could I don't know that mutual authentication is the only property you're looking for. I think this also includes "data integrity and protection against replay". See, e.g., RFC 4949 "Authentication Header". FWIW, I think this bit of text will raise the ire of the security directorate folks no matter how carefully we try to get it right. I'd suggest simply flagging this now and proactively ask them what we should put here. > Where the security considerations outlined above are a concern, users > of this protocol should consider using some type of transport that provides > mutual authentication, data integrity and transport protection, such > as IPsec [RFC4303] or TCP-AO [RFC5925]. If confidentiality is > considered a concern, a transport providing that as well could be > selected. I think the security directorate will be happy to see this. -- Jeff _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
