Experience with the BGP-4 Protocol
Summary: Needs a YES.
Note: This ballot was opened for revision 04 and is now closed.
( Steven Bellovin ) Discuss
Discuss (2004-07-22 for -)
draft-ietf-idr-bgp4 18.104.22.168: what is the "longest route"? The longest prefix? The longest AS path? draft-ietf-idr-bgp-vuln section 1: Address-spoofing should be listed as a possible form of damage. Also discuss how this enables active attacks on traffic, by routing it through a modifier station. draft-ietf-idr-bgp-analysis The document speaks of versions 1, 2, and 3 of BGP-4 draft-ietf-idr-bgp4-experience-protocol The document speaks of 134,000 prefixes; draft-ietf-idr-bgp-analysis speaks of 120K. Which is it? Section 7.1.1: s/potatoe/potato/ (unless the authors subscribe to the Dan Quayle school of spelling) Some of the subsections of Section 17 appear as if they should be sections.
Comment (2004-07-21 for -)
draft-iesg-tcpmd5app recuse Several of the documents have their own security analysis, instead of referring to draft-ietf-idr-bgp-vuln. Perhaps the information should be merged (if necessary), and the extra text deleted from the other drafts.
( Bill Fenner ) Yes
( Alex Zinin ) (was No Record, Yes) Yes
Comment (2004-07-15 for -)
Some comments that should be addressed when the documents are revised. draft-ietf-idr-bgp4-experience-protocol: From my previous review: > I'm generally quite happy with this document. The only comment I had was about > the way the 2119 requirements language is used. In some places (simple search > for "MUST" would reveal), the document reads as defining protocol procedures, > which should be in the protocol spec. If the intention is to quote the spec, > the wording should be changed accordingly. > Refs to SBGP and SoBGP should be filled in. There are still one place where the above problem exists: > 7.1.2. Sending MEDs to BGP Peers > [BGP4] allows MEDs received from any EBGP peers by a BGP speaker to > be passed to its IBGP peers. Although advertising MEDs to IBGP peers > is not a required behavior, it is a common default. MEDs received > from EBGP peers by a BGP speaker MUST NOT be sent to other EBGP > peers. The document also needs new boilerplates per 3667/3668. draft-ietf-idr-bgp-implementation-01.txt: > 1. Introduction > > This revision of the BGP-4 standard [BGP4] updates the BGP standard > [RFC1771] to be in alignment with the deployments of the BGP-4 > protocols. BGP-4 as deployed in the Internet encompasses both this > base specification and additional specifications such as TCP MD5 > [RFC2385], BGP Route Reflectors [RFC 2796], BGP Confederations > [RFC3065], and BGP Route Refresh [RFC 2918]. Don't "This revision of the BGP-4 standard" and "this base specification" give the reader an impression that this document is the revision and the base specification? > 2.3 BGP Implementation Identification The origins of the implementations are still not specified. draft-ietf-idr-bgp-analysis-05.txt: > 2.1. Key Features ... > One of the most important path attributes is the Autonomous System > Path, or AS_PATH. Autonomous System's (AS) reachability information ^^^^^^^^^^^^^^^^^^^^^^^^ Is this really what you meant here? The original text said "AS reachability info...", I commented if is should have been "As", i.e. whether it should read "as ... info travereses... it is augmented..." > traverses the Internet, this information is augmented by the list of > autonomous systems that have been traversed thus far, forming the > AS_PATH. ... > 6.1. Link bandwidth and CPU utilization ... > > BW = O((N + A) * P) > > The following table illustrates the typical amount of bandwidth The table is missing in the text. > 6.1.1. CPU utilization ... > During the periods of network instability, BGP routers within the > network are generating routing updates that are exchanged using the > BGP UPDATE messages. The greatest overhead per UPDATE message occurs > when each UPDATE message contains only a single network. It should > pointed out that in practice routing changes exhibit strong locality "it should BE pointed out" When you revise the draft, please include the new boilerplates required by 3667/3668. draft-ietf-idr-bgp4-24.txt: needs new boilerplates
( Harald Alvestrand ) (was Discuss) No Objection
Comment (2004-12-02 for -05)
draft-ietf-idr-bgp-implementation-01 and -02 reviewed by Mary Barnes, Gen-ART draft-ietf-idr-bgp4-24 and -26 reviewed by Brian Carpenter, Gen-ART draft-ietf-idr-bgp4-mib-14 reviewed by John Loughney, Gen-ART draft-ietf-idr-bgp-vuln-00 reviewed by Kent Crispin, Gen-ART -01 reviewed by Elwyn Davies, Gen-ART draft-ietf-idr-bgp-analysis-05 reviewed by Lucy Lynch, Gen-ART -06 reviewed by Elwyn Davies, Gen-ART draft-ietf-idr-bgp4-experience-protocol-04 reviewed by Mark Allman, Gen-ART -05 reviewed by Suzanne Woolf, Gen-ART draft-ietf-idr-bgp-mibagent-survey-02 reviewed by Michael Patton, Gen-ART draft-iesg-tcpmd5app-00 reviewed by Spencer Dawkins, Gen-ART I have added reviews as comments on the individual documents, not on the ballots. There are no show-stopper issues identified, but lots of details worthy of notice (still).
( Ted Hardie ) No Objection
Comment (2004-07-20 for -)
In draft-ietf-idr-bgp4-24.txt, an informative reference to RFC1930 seems likely to be useful, especially since that reserves specific ASNs as private use. The abstract in draft-ietf-idr-bgp4-mib-14.txt says: This memo is an extension to the SNMP MIB. It obsoletes RFC 1657 and RFC 1269.. That doesn't seem quite right. 1657, which this obsoletes, says: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Border Gateway Protocol Version 4 or lower [1, 2]. An extension to the SMI, maybe, instead of the snmp mib? In draft-idr-bgp-implementationt: The abstract states the the editors make no claim as to the accuracy of the information provided. This is repeated in section 1. Not blocking but this seems strange in an implementation report. In draft-ietf-idr-bgp4-experience-protocol-04.txt , I assume the RFC Editor will talk to them about "hot potatoe" spellings in US terms. This sentence: Seemingly more intuitive references that fall outside the vegetable kingdom refer to cold potatoe routing as "best exit routing", and hot potatoe routing as "closest exit routing", though vegetable. also looked like it might have gotten interrupted in mid-edit. I note the this document says that folks use IPSEC to protect BGP in some circumstances, where the TCPmd5 variance says that IPSec and TLS are rarely if ever used. Not blocking, just thought it worth noting that these don't quite agree. Hopefully this means folks are looking at how to augment TCPmd5.
( Sam Hartman ) No Objection
( Scott Hollenbeck ) No Objection
Comment (2004-07-15 for -)
draft-ietf-idr-bgp-mibagent-survey: The Security Considerations should be something more detailed than "This document does not address any security issues". If anything, those words are an admission that something more should be written! A reading of RFC 3552 would explain why I think this could be better, even if there's not much in this document that has a security impact. draft-ietf-idr-bgp4-experience-protocol: draft-ietf-idr-bgp-vuln: References need to be split normative/informative.
( Russ Housley ) (was Discuss) No Objection
Comment (2004-07-21 for -05)
draft-idr-bgp-implementation-01: The abstract and the introduction state that the the editors make no claim as to the accuracy of the information provided. It would be much better to make a positive statement in the introduction, and say nothing in the abstract. Perhaps something like: The editors have assembled information provided by four implementors: Alcatel, Cisco, Laurel, and NextHop. draft-ietf-idr-bgp4-24: Please replace the first sentence of the Security Considerations with: A BGP implementation MUST support the authentication mechanism specified in RFC 2385 [RFC2385]. draft-ietf-idr-bgp4-mib-14: The security considerations section contains non-ASCII characters. draft-ietf-idr-bgp-vuln-00: Nice job. It would have helped me if the event tags had been explained before I encountered the first one in section 3.1.1. Perhaps an additional paragraph in section 3 would explain them. In the whole document: s/IPSEC/IPsec/ In section 1, 5th paragraph: s/msut/must/ The lists in section 1 and section 2 have a different format. In section 1, each item in the list ends with a comma (the "and" appears one entry before it should), and in section 2, the list members are full sentences. I would like to see the same style for both lists. draft-iesg-tcpmd5app-00: The security Considerations say: > > The IESG believes that the variance described here will not affect > the security of the Internet. > I think we should insert "adversely" before "affect." draft-ietf-idr-bgp4-experience-protocol-04: In section 17.6: s/rationelle/rationale/ Section 17 includes stuff that is not security relevant, including the acknowledgements section. A minor reorganization is appropriate.
( David Kessens ) No Objection
( Allison Mankin ) No Objection
( Thomas Narten ) (was Discuss, No Objection) No Objection
( Jon Peterson ) No Objection
( Margaret Wasserman ) (was Discuss, No Objection) No Objection
( Bert Wijnen ) (was Discuss) No Objection
Comment (2004-12-02 for -05)
------- draft-ietf-idr-bgp-implementation-01.txt ------- Section 1 speaks about: Section 1.3 provides the quick survey results on inter-operability. Section 1.4 provides an inter-operability of the 4 implementations. but there are no such section 1.3 and 1.4 Actually, the whole numbering of sections needs to be checked I think. ---------- Additional Comment from Pekka on 26 Nov 2004: > Procedural: > > 1) > > The results of the implementation report do not seem to be completely > reflected in the document. For example: > > b) SHALL NOT - Question 228, regarding section 22.214.171.124 > > Three vendors (Alcatel, Cisco, Laurel), answered "N" to shall > not (meaning they did). One vendor (NextHop) indicated "O" > matching the specification. > > Text: Routes that have different MULTI_EXIT_DISC attribute > SHALL NOT be aggregated. > > ==> one implementation does not fulfill the criteria of two > implementations of a feature, which is required prior to advancing to > Draft Standard. Therefore the BGP specification must be changed. > > I have not gone through the implementation report in detail, but it > should be carefully reviewed to ensure that features for which there > aren't at least two interoperable implementations are removed. > > > 2) A normative reference may need to be moved over to Informative: > > Normative References: > [RFC2474] Nichols, K., et al.,"Definition of the Differentiated > Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474, > December 1998 > > ==> this is a Proposed Standard, and a Draft Standard cannot > reference it normatively. > > Nit: > 'Working Group Summary' in the announcement needs to be updated. > >