Subject: RE: draft-ymbk-l3vpn-origination-02

From: "Arjun Sreekantiah (asreekan)" <[email-masked]>
Date: Thu, 15 Nov 2012 01:59:49 +0000

Bruno,
Thanks for the comments. Replies below

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, November 12, 2012 1:44 AM
To: Arjun Sreekantiah (asreekan)
Cc: [email-masked]
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.

---

From: <[email-masked]>
Date: Thu, 15 Nov 2012 09:25:02 +0000

Arjun,

Thanks for your reply. 

Please see inline.

Bruno

>From: Arjun Sreekantiah (asreekan) [mailto:[email-masked]] >Sent: Thursday, November 15, 2012 3:00 AM
>
>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.
>
>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.
>

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

>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

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.

---

From: <[email-masked]>
Date: Thu, 15 Nov 2012 14:43:18 +0000

Hi Arjun,

Arjun Sreekantiah:
> Please note that the scheme does provide protection against attack scenarios as well, this is not just protecting errors from configuration.

If only the NLRI is signed, as specified in the dratf, and not the 
attributes nor the rest of the MP_REACH_NLRI attribute, how does it 
provide an efficient protection against attacks ?

-Thomas

---

From: "Arjun Sreekantiah (asreekan)" <[email-masked]>
Date: Sat, 17 Nov 2012 01:07:33 +0000

Bruno,
More inline.

>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.
>
>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.

>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.
>

>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]
>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.

>   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.

>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.

Please see above for this statement referred to.

Thanks
Arjun

---

From: "Arjun Sreekantiah (asreekan)" <[email-masked]>
Date: Sat, 17 Nov 2012 01:08:11 +0000

Hi Thomas,
Attributes in the BGP update such as the nexthop and aspath are rewritten/modified at the ebgp boundary so signing the attributes at the originator is of little value unless the same is done at each hop,
In which case we are attempting path validation - this would introduce a lot more complexity into the solution and require intermediate hops to be aware of the scheme - The primary scope of the draft is to accomplish origin validation for VPN routes (verify routes are coming from valid originator)  similar to the RPKI based  prefix validation for internet.

Thanks
Arjun
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, November 15, 2012 6:43 AM
To: [email-masked]
Subject: Re: draft-ymbk-l3vpn-origination-02

Hi Arjun,

> Please note that the scheme does provide protection against attack scenarios as well, this is not just protecting errors from configuration.

If only the NLRI is signed, as specified in the dratf, and not the attributes nor the rest of the MP_REACH_NLRI attribute, how does it provide an efficient protection against attacks ?

-Thomas

---

From: <[email-masked]>
Date: Mon, 19 Nov 2012 09:18:22 +0000

Arjun,

Thanks for your reply.
More inline.

>From: Arjun Sreekantiah (asreekan) [mailto:[email-masked]]
>
>Bruno,
>More inline.
>
>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).

>>Regardless, we would probably all agree that enabling BGP communities is
>easier than deploying ymbk-l3vpn-origination
>
>[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

>_______________________________________________________________________________
>__________________________________________
>
>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.
>As emails may be altered, France Telecom - Orange is not liable for messages
>that have been modified, changed or falsified.
>Thank you.

---

From: Randy Bush <[email-masked]>
Date: Tue, 20 Nov 2012 10:04:16 +0700

being lazy, i really wanted to spec communities.  but communities are
too small to hold a reasonable hash.  and they are not necessarily
transitive.

randy

---

From: <[email-masked]>
Date: Fri, 23 Nov 2012 14:16:17 +0000

Hi Randy,

>From: Randy Bush [mailto:[email-masked]] >Sent: Tuesday, November 20, 2012 4:04 AM
>
>too small to hold a reasonable hash. 

Regular community may be too small to protect from attacks but probably not to protect against unintentional errors, which is the goal of the draft as per the abstract.
That's why IMO, the draft should clearly states what are the VPN customers' requirements in term of protection and how much the draft address thoses requirements.
In addition, a few uses cases would be useful to better understand the issues the draft is proposing to solve.

Extended community are bigger (6 or 7 octets). Not working on crypto, I don't know if that's big enough to sign an IP prefix. 

> and they are not necessarily transitive.

If you pick the transitive flavor, I assume that the SP(s) will not specifically filter out the customers' communities as the SP is supposed to provide a transparent IP VPN service.
(and we could argue that the "L3VPN Origination BGP Path" Attribute is also not guaranteed to be transitive (e.g. to protect from BGP session failure caused by incorrect handling of BGP attributes, SP could filter out the attributes)

Bruno

---

From: Randy Bush <[email-masked]>
Date: Fri, 23 Nov 2012 22:01:45 +0700

> Extended community are bigger (6 or 7 octets). 

crypto folk all say too small

randy