Bruno, Thanks for the comments. Replies below -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Monday, November 12, 2012 1:44 AM To: Arjun Sreekantiah (asreekan) Cc: [email protected] Subject: draft-ymbk-l3vpn-origination-02
Arjun, all, I confess that I don't know much about SIDR, but I guess that I'm not the only one in L3 VPN. Therefore clarification may be useful for the L3 VPN WG. Let's assume that no RPKI is used. 1) Given that the goal is to protect from unintentional errors, can you elaborate on the added value brought by l3vpn-origination compared to the use of a (extended) community agreed upon the VPN sites (e.g. some kind of a shared password)? The latter being available now, how much is it deployed/used now? (I would assume that l3vpn-origination would be used by a subset of such current users) [Arjun] Please note that the scheme does provide protection against attack scenarios as well, this is not just protecting errors from configuration. Using a community or extended community makes it vulnerable in a attack scenarios. It is easy to figure out the community or extended community value for prefixes for that VPN simply by looking at the BGP update or some show command output for the prefix in that VPN. In the scheme, we use a digest generated from a secret (possibly shared ) key and hence this is not easy to decipher. Also, communities (and extended communities) are not propagated across the ebgp boundary by default. 2) Can you elaborate on how l3vpn-origination protects from unintentional errors by the legitimate originator? Seems to me that both correct and erroneous routes would be signed by the egress CE/PE and hence accepted by the ingress. [Arjun] The idea here is to protect against routes being originated from unintended/unauthorized sources (similar to RPKI based prefix validation), so any spurious routes sourced in transit can be detected and dealt with in the appropriate manner. Detecting erroneous routes coming from the proper originator itself is beyond the scope of what is defined. 3) Given that a VPN may want to import routes from outside of the VPN (e.g. provider IP services (e.g. voice gateway), extranet), how does l3vpn-origination protect from unintentional errors from those partners? [Arjun] For simplicity we would recommend sharing keys with the extranet partners, voice gateway sources this does mean that errors originating from those sources will not be protected. Again we would expect these services to be trusted sources. Thanks Arjun Thanks for the clarifications, Bruno _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you.
