Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3 VPNs
draft-ietf-l3vpn-bgpvpn-auto-09
Discuss
Yes
(Mark Townsley)
No Objection
(Dan Romascanu)
(David Kessens)
Abstain
(Lars Eggert)
Recuse
(Ross Callon)
No Record
Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
(Cullen Jennings)
Summary: Needs a YES.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Magnus Westerlund Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2006-11-30)
Unknown
draft-ietf-l3vpn-vpn-vr 12. Quality of Service This architecture can utilize a variety of Quality of Service mechanisms. QoS mechanisms developed for physical routers can be used with VRs, on a per-VR basis, including classification, policing, drop policies, traffic shaping and scheduling/bandwidth reservation. The architecture allows separate quality of service engineering of the VPNs and the backbone. The topic of QoS in a VR architecture appears to me to be substantially more complex than the above text indicate. A VR solution will have the normal issues with handling resource and marking across the boundaries from inside to outside a tunnel. In addition there will be issues with translating different QoS models or adapt to different types of engineering between the different levels of VPNs and the real network. The chapter should be rewritten to indicate that although there are possibilities they will not be a general as one might think. And in addition there should be some references to the issues that exist. This also impact section 14 in draft-ietf-l3vpn-as-vr.
Russ Housley Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2006-11-29)
Unknown
Eric Rescorla provided IETF Last Call comments (his SecDir Review) on draft-ietf-l3vpn-as-vr-02. No response was posted. His comments were significant in my view, and I think that a response is needed in order for me to determine if the working group considered the issues that Eric raised.
Mark Townsley Former IESG member
Yes
Yes
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2006-11-29)
Unknown
draft-ietf-l3vpn-bgpvpn-auto-08.txt Lists 2119 but does not cite it. Contains one inappropriate MUST. "Two interwoking scenarios are considered..." Interesting thought :-) draft-ietf-l3vpn-as-vr-02 (from Spencer Dawkins) This document dates from the PPVPN days (before L2VPN and L3VPN split into two working groups). If there is any energy left for editorial changes, it might be nice to make it more clearly an L3VPN document - less confusing for the reader, anyway. Should this and draft-ietf-l3vpn-vpn-vr-03.txt contain a statement that they are being published for the record?
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2006-11-29)
Unknown
> An important consideration to remember is that one may have any > number of INDEPENDENT BGP systems carrying VPN-related information. > This is unlike the case of the Internet, where the Internet BGP > system must carry all the Internet routes. Thus one significant > (but perhaps subtle) distinction between the use of BGP for the > Internet routing and the use of BGP for distributing VPN-related > information, as described in this document is that the former is not > amenable to partition, while the latter is. Yes. But given what we learned in the routing and addressing workshop, perhaps there should still be a warning that VPN-related BGP information can still form a large fraction of the entire routing table in a provider site.
Lars Eggert Former IESG member
Abstain
Abstain
()
Unknown
Ted Hardie Former IESG member
Abstain
Abstain
(2006-11-29)
Unknown
This abstain comment applies to draft-ietf-l3vpn-bgpvn-auto. I believe that the security considerations section is problematic. It says, in particular: It is of critical importance that a particular PE should not be "discovered" to be attached to a particular VPN unless that PE really is attached to that VPN, and indeed is properly authorized to be attached to that VPN. If any arbitrary node on the Internet could start sending these BGP advertisements, and if those advertisements were able to reach the PE routers, and if the PE routers accepted those advertisements, then anyone could add any site to any VPN. Thus the auto-discovery procedures described here presuppose that a particular PE trusts its BGP peers to be who they appear to be, and further that it can trusts those peers to be properly securing their local attachments. <snip> If a particular remote PE is not a BGP peer of the local PE, then the information it is advertising is being distributed to the local PE through a chain of BGP speakers. The local PE must trust that its peers only accept information from peers that they trust in turn, and this trust relation must be transitive. BGP does not provide a way to determine that any particular piece of received information originated from a BGP speaker that was authorized to advertise that particular piece of information. Hence the procedures of this document should be used only in environments where adequate trust relationships exist among the BGP speakers. The problem, certainly not unique to this document, is that the set of bgp speakers can change as the path changes and any particular bgp speaker cannot directly evaluate the trust relationships between peers distant in the path. That creates the transitive trust requirement that the document notes. In many cases, the potential set of bgp peers to which transitive trust might have to be extended is not bounded. Put another way, the document describes a risk, and it should stop there--there is a risk that someone injecting false information into BGP would allow unauthorized hosts to attach to a VPN. Assuming that there will be environments where the transitive trust relationships are sufficient to avoid this problems seems to me to presume a stability in the set of actors which may not be appropriate over time even in environments where adequate trust relationship exist initially. It also might be taken as encouraging the common, but not very useful, idea that there are security perimeter aspects to the vpn network topology. This is not a discuss because these are informational documents and because they are no longer the subject of active work.
Ross Callon Former IESG member
Recuse
Recuse
()
Unknown
Cullen Jennings Former IESG member
(was No Objection)
No Record
No Record
()
Unknown