Bruno, More inline. >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'." [Arjun] The primary motivation behind the draft is mis-configuration aka 'fat fingers' but the digest scheme does provide more security wise than just using a "secret" community. Once the secret community value Is known the same could be used to compromise any prefix from the originator whereas with the digest scheme, you would need to snoop out the digest value associated with each prefix since there is a unique digest per prefix. Granted the scheme does not address replay attacks (this is what section 7 is referring to), but neither do well known schemes for origin validation like RPKI based prefix validation so this is similar. ( this is a tradeoff to keep the solution simple) Also the community based scheme is not as simple to implement as it would appear. You would need to make sure that the secret community values do not collide with valid community values used in policy elsewhere, this would been more difficult to do, when you need a unique community value per VPN. Also you need to make sure that these values are not stripped or interpreted in a different manner by transit ASes and also need to make sure that transit ASes propagate the community values transparently which would now require the intermediate hops to be aware of the scheme. > 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 [Arjun] Please see my comment above - this would have its own complexity. >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." [Arjun] This is referring to the fact that a PE attaching a site to the wrong VPN can be a legitimate originator with fat fingering which is covered by the scheme. I was referring earlier to some fat-fingering on the CE Sourcing and signing the route itself which is beyond the scope. We can add text to clarify this part - Thanks for pointing it out. > >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." [Arjun] Please see above for this statement referred to. Thanks Arjun > >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.
