Arjun, Thanks for your reply.
Please see inline. Bruno >From: Arjun Sreekantiah (asreekan) [mailto:[email protected]] >Sent: >Thursday, November 15, 2012 3:00 AM > >-----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. [Bruno]. The draft claims differently. I.e. only for protection against unintentional errors "Abstract A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are subject to unintentional errors, both by the legitimate originator and by non-legitimate origins." "7. Security Considerations This is not protection against attacks, only configuration errors, aka 'fat fingers'." > 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. I would tend to disagree for regular communities. Regardless, we would probably all agree that enabling BGP communities is easier than deploying ymbk-l3vpn-origination >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. That does not seem to match the first sentence of the abstract: " A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are subject to unintentional errors, both by the legitimate originator and by non-legitimate origins." > >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. In this case, the draft does not solve the problem it has defined in the abstract. "A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are subject to unintentional errors, both by the legitimate originator and by non-legitimate origins." Bottom line: You need to make clear in the draft what the problem statement is i.e. the problem that you want to solve. This is not very clear currently. Thanks, Bruno > >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.
