FYI...
Begin forwarded message: > From: Sandra Murphy <[email protected]> > Date: October 28, 2010 10:27:29 AM PDT > To: [email protected], [email protected], [email protected] > Subject: comments on draft-irtf-rrg-recommendation-14 > > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > I unfortunately was off-net for a few days and got to this assignment rather > late. The document is long and covers a broad swath of material and I was > not able to cover it deeply. > > This document is a product of the rrg IRTF working group. It summarizes 15 > different proposals for a new routing and addressing architecture for the > Internet, with short summaries, critiques and rebuttals for each, and gives a > final recommendation to the IETF for future direction. > > With the breadth of scope of the document, there is no way for me to review > each proposal's documents for security considerations. > > The security considerations of *this* document itself is quite terse: > > 20. Security Considerations > > All solutions are required to provide security that is at least as > strong as the existing Internet routing and addressing architecture. > > Given the widely reported weakness of the "existing Internet routing and > addressing architecture", this is a low bar indeed. There are attempts in > progress to attempt to improve the security of the Internet routing and > addressing architecture. I do not know what to suggest if these improvements > leave the Internet with stronger security than is provided by these proposals. > > The summaries of the different proposals devote little attention to the > infrastructure security ramifications of the proposal. Given the stated > goal, perhaps no attention was necessary. > > Many of these proposals include an encapsulation system, presenting the > expected difficulties with end system authentication, filtering systems at > boundaries, etc. Some proposals addressed these concerns. I am not sure if > the security considerations section meant that the proposals were required to > avoid weakening the end-host security protections already provided (ipsec, > NAT, whatever). > > The rrg wg came to consensus that a fundamental architectural feature is a > separation of locator and identifier for any node. Many of the discussed > alternatives include a mapping system that produce a locator for a given > destination identifier. > > The mapping system would seem to be a very likely point of vulnerability, > permitting traffic redirection for data exposure or blackholing, etc. Many > proposals suggest a hierarchic architecture of the mapping system for scaling > purposes. I would presume that an authorization scheme for the mapping > system would be essential, and that the hierarchy would be an important > aspect of that scheme. Of course, I can't tell much at this level of detail > about how and if each proposals addresses this. (One of the recommendations > suggests communicating mapping info through bgp - I can not say at this point > whether the SIDR suggestions for improving bgp security would be applicable.) > > --Sandy > > Nits: > > PMTUD Path Maximum Transmission Unit Discovery: The process or > mechanism that determines the largest packet that can be sent > between a given source and destination with being either i) > fragmented (IPv4 only), or ii) discarded (if not fragmentable) > because it is too large to be sent down one link in the path from > the source to the destination. > > It should say "*without* being either", right? A long sentence so I may have > lost my place. > > > Several of the comments start using terms that are part of the wg > deliberations, I'm sure. But it makes reading the discussions and critiques > obtuse. In particular, "Core-Edge Separation" and "Core-Edge Elimination" > seems to a well understood concept in the wg. It needs to be defined > somewhere. A web search found references in some conference papers and in > rrg mailing lists. _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
