Hello Daniel,
> I have reviewed this document as part of the Internet directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > internet are a directors. Document editors and WG chairs should treat > these comments just like any other comments. Thank you for your review. Please find my responses in-line. I would appreciate your comments on my points. > I must first clarify that I am not an expert in BGP, so I may be > lacking some context. I have included my comments inline. Thank you for being upfront about this, this is really appreciated. > 3.1. BGP Session Protection > > To protect a BGP speaker on the network layer, an operator MUST > ensure the following properties using technical or organizational > measures: > > * Prevent off-path attackers from injecting BGP messages into > existing sessions. > > mglt: It is my belief that protection does not consist in preventing > off-path attacker, but instead to prevent injection from off path > attacker. My understanding of on off path attacker is that the > attacker while not being able to access the link is able to send some > message. I do not necessarily see the need to specify this is a off- > path attacker as the same should be true for an on-path attacker. At > last injection may not only consists of BGP messages, but any type of > messages. As a result, I would reformulate the requirement above as: > Prevent traffic injection into BGP session The problem here is that BGP sessions are usually TTL 1 connections between two directly adjacent hosts. While techniques for ensuring integrity of these sessions exist (see TCP-MD5 and TCP-AO below), these do not see wide-spread use (While, still, being certainly recommended). As such, there is a qualitative difference between on- and off-path attackers, with the former being---in practice---harder to defend against. Hence, the (weaker) differentiation by explicitly naming off-path attackers. > * Prevent off-path attackers from interrupting existing sessions. > > mglt: I have the impression interrupting existing session will > require somehow the injection of packet in the session or in a kind > of control plane. Unless I misunderstand it this requirement is > covered by the one above. Not necessarily. This could also be accomplished by, e.g., overloading the control plane due to a SYN flood on an exposed port 179; Keep in mind that session re-establishment also means significant convergence time depending on the number of routes exchanged. Hence, loss of just a few packets may already trigger a session re-establishment. > * Prevent remote systems from overwhelming the BGP speaker by > sending large volumes of unsolicited packets or BGP messages. > > mglt: I think this requirement is to protect the BGP speaker from > resource > exhaustion due to large volumes of unsolicited packets or BGP > messages. > > * Ensure that unstable sessions do not threaten the availability > of > BGP speakers within the network. > mglt: this requirement seems covered by the previous requirement. No; An unstable session (constantly up-down-up-down, i.e., 'flapping') leads to constant reconvergence, and, hence, load on the routing engine. This may not even neccesarrily be malicious. > mglt: I do not see what the text below adds. Whatever way could be > used this MUST NOT happen. > > in a way that allows > tainting confidentiality, integrity, or availability. Yes, but sometimes access to the management plane is required for unauthorized third parties, e.g., indirectly via looking glass services that (sometimes) allow executing commands on routers. > * External activity towards the management interface does not > interfere with the integrity or availability of BGP sessions. > > mglt: my understanding of the management plane is that one can switch > off the router. If the requirement is that each external user is > being provided some fucntionnalities This is, again, similar to the above point; I.e., it would not be good if, in cases where the management engine co-locates with the routing engine, e.g., a flood against the management ports or excessive SNMP walking causes high CPU load, which, in turn tears down sessions. > 4. NLRI Filtering > > ... > > mglt: In my opinion checking the information is authorized / > legitimate is essntial BUT this is not sufficient. We also need to > check it has actually be sent BY the legitimate origin which is done > via signataure. There is no end-to-end signature scheme for BGP. BGP updates are inherently un-signed. 8205ff would provide some options here, but is hardly relevant in practice. > 4.2. Originating and Redistributing NLRI > > ... > > mglt: same redistributor or origin MUST be authenticated to ensure > the action is not only legitimate BUT is requested. BGP works announcement based. Updates are never requested, and there is no end-to-end authentication in BGP. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M [email protected] Pronouns: he/him/his _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
