Arjun, Thanks for your reply. More inline.
>From: Arjun Sreekantiah (asreekan) [mailto:[email protected]] > >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' OK. In this case the problem is that the solution defined in the draft does not help protecting from mis-configuration from the people who can do it: service provider, extranet VPN. You agreed on this in your previous email: http://www.ietf.org/mail-archive/web/l3vpn/current/msg03490.html It does protect from mis-configuration from people who cannot send routes in the VPN... But this is also of limited value because in this case this would probably be an attack so you would need to provide protection against attacks. (And personally, as an attacker, may be I would rather play with the MPLS labels which seems more powerful and more difficult to detect) >but the digest scheme does provide more security wise than just using a >"secret" community. The question is: how much more. Then we can discuss how much the additional cost outweighs the additional benefit. > 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) Although I'm not familiar with the SIDR work, I see a significant difference: in the Internet, IP routes are public and hence you can use a database to check who is allowed to originate a given route. This is not the case in a VPN context. That's why IMHO, the level of protection provided is significantly lower. >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. In short, you need to know how to use a BGP community. IMO, people knows. Note that this is a pre-requisite for L3 VPN (route distribution are based on extended community). > >> 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. This is indeed covered in the subcase " 5.1. End CE to CE Authentication" However, in the sub-case, "5.3. PE-PE Based Validation", this is very debatable: a) you assume a mis-configuration (of the RT) on the PE from the SP b) to detect this you rely on the correct configuration (of the key) on the PE from the SP. Seems to me that "b" is debatable if you assume "a". (in short, do you trust the configuration, or not?) > 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. Ok. Thanks. For the same reason, could you also add that: - for the sub-case "5.3. PE-PE Based Validation", fat-fingering on the PE is beyond the scope of the document - in case of extra-net, fat-fingering on the partner(s) VPN is beyond the scope of the document - in case the SP originates routes in the customers VPN (e.g. voice gateway, cloud services....) fat-fingering in the SP is beyond the scope of the document Thanks. Bruno >>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. _________________________________________________________________________________________________________________________ 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.
