On 19 Nov 2013, at 10:01 am, [email protected] wrote:
In the unfortunately rich and lengthy saga relating to efforts to secure BGP, I understood that the way things were arranged in the IETF to tackle this topic was that the RPSEC working group was tasked with documenting the requirements for work on technology for securing BGP. The WG managed to achieve consensus on requirements for origination, but never managed to completely resolve some difference of opinion over AS Path requirements. Some WG members evidently felt strongly that what was necessary and sufficient was that the AS PATH attribute should accurately reflect the sequence of AS's traversed in the propagation path taken by the NLRI, and that this was necessary and sufficient. Others disagreed. Some disagreed on the basis that the update path was not necessarily precisely aligned to the asserted AS Path. and others disagreed because even correct protocol operation was still vulnerable to behaviours that looked like policy violations (e.g. customers transforming themselves into transit ASs for certain prefixes). The SIDR WG at the time was chartered to work on requirements as they were provided by the RPSEC WG, and at one point, as I understood it, the Routing ADs at the time got impatient with RPSEC and effectively directed the SIDR WG to commence work on securing the AS Path attribute in the absence of agreed requirements from RPSEC, and placed into the charter of the SIDR WG a set of requirements that were aligned to the "protocol correctness" perspective, and thereby ignored the other considerations relating to path validation. The ideas presented in this route leaks draft are by no means novel - the archives of RPSEC probably contain this same material many times. But the underlying issues it exposes are very real, and it does expose what for me is a critical weakness in the decision by the Routing ADs at the time: hasty decisions that attempt to gloss over deep divisions are generally very poor decisions.The deeper issue in the path discussion in RPSEC was a discussion over policy intent vs protocol correctness. This draft contains a good example of this - in terms of protocol a customer propagating to one (or more) of its transit upstreams routes learned from other upstreams is not incorrect in terms of protocol operation - and non-policy-based AS Path security mechanisms will not detect the anomaly. So what ARE the requirements for path validation in a secure model for BGP? Is it like DNSSEC where, if I paraphrase the DNSSEC objective: "If everybody signed everything in the DNS, then any form of lies in DNS responses would be readily exposed as such by anyone who cared to look"? Or is it a far weaker requirement: "We just want to reduce, but not eliminate, the number of ways in which actors can lie in BGP"? We have the latter form of outcome. All this work in SIDR is intended to reduce the ways in which you can lie in BGP, not to allow any party to detect any form of perversion of routing updates. Its by no means a "complete" solution to securing inter-domain routing, but in our haste to comply with the timelines dictated by DHS's project funding I guess we've got what DHS were prepared to pay for, and not what we actually wanted or need. And for many its an unsatisfactory outcome. So with this WG draft, it looks to me GROW is now hosting a re-opening a discussion of the requirements for AS Path validation in BGP, and once again examining the differences between correct protocol operation vs correct alignment to routing policy intent. Why are we using GROW to host this discussion? What are GROW's intended objectives in considering this draft? And if I ignore the WG / Area IETF procedural gunk, on a more general level, are we ready to admit that the work performed by SIDR has been performed to such a level of haste that the quality of the underlying security mechanisms are compromised by attempting to drive the process according to a timetable largely dictated by the requirements of the major external funding agency at the time, namely the DHS? And if we are ready to reopen this consideration of requirements for securing the operation of BGP, just how much of this are we willing to re-consider? Is it all the way back to RPSL and RPSS? Geoff |
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
