Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

[John Scudder <[e-mail]>]

(Still as a WG contributor, except where indicated.)

On Jun 11, 2019, at 5:50 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:

John,

Thank you very much for the explanation, especially the analysis on “Remote Endpoint” not constrained to the BGP speaker that originates the Tunnel-Encap Update. Just wish the authors can add the explicit description to the document, to avoid confusion to many people.

(This part is with my co-chair hat on.)
Considering the document is past WGLC with decent support and engagement, my working assumption is that this comment (that the document is confusing) is what the IETF process calls “in the rough” — that is to say, not wrong (how could it be wrong for you to say you found it confusing? It’s a statement about your own personal reaction, after all), but not an opinion shared by others.
(End of co-chair comments, back to “WG contributor.)

Is my following understanding correct?

When a node R sends the Tunnel-Encap with “remote endpoint” address being A, does it mean that any node (which can be many nodes) receiving the Update can assume that node A has the capability described by the Tunnel-encap (such as supporting the specific encap)?  If a receiving node, say B, doesn’t support the capability being advertised by this Tunnel-Encap, the Node B basically ignore the Tunnel-Encap Update?

That matches my understanding.

If the node R encodes wrong Encap capability for remote endpoint A, i.e. wrongfully advertises remote endpoint A supporting VxLAN Encap (but Node A actually doesn’t),  Node B will send VxLan encapsulated data frames to A upon receiving the Update.

Again, that is my understanding.

How does RFC6811 handle this issue?

I think you can break this down into two cases: misconfiguration, and attack. RFC6811 doesn’t do anything to prevent someone who genuinely does administer both node R and remote endpoint A from configuring things wrong. However, RFC6811 can provide some better-than-nothing level of checking against an attack, as outlined in section 13, essentially by checking that R and A are under a common administration. As section 13 goes on to say, you shouldn’t rely too much on this, because the security assurances provided by RFC6811 are not strong — it’s rather easy to forge a source AS if you are a genuinely malicious attacker, for example. However, these are issues that exist in the base BGP protocol and as we discussed earlier also exist in RFC5512 and basically, every use of BGP other than those within walled gardens, or BGPSEC. So, I think we can say tunnel-encaps is not worse than RFC5512 in this respect, though it may not be better or at least much better, either.

Regards,

—John


Linda



From: John Scudder <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, June 11, 2019 4:07 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: Keyur Patel <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

(Still as a WG contributor…)

Hi Linda,


On Jun 11, 2019, at 4:41 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:

John,

Before I elaborate for more scenarios, I would like to get the answer to the following question:


  *   Does the “Remote Endpoint” in draft-ietf-idr-tunnel-encaps-12 represent the BGP speaker that originates the update? Or the remote end point that the “Tunnel” is established to?

     *   I have been told two different versions of the answers. I need confirmation from the authors.


I’m not an author of course but I’ll provide my own reading for the sake of continuing the discussion. I just reviewed section 3.1 of the draft, and based on that review it’s my opinion that the Remote Endpoint is clearly not constrained to represent only the BGP speaker that originates the update. Reasons for thinking this include:

- There is no text stating that it’s so constrained. “Everything is permitted except that which is forbidden.”
- There is a detailed set of validation procedures. If the authors had wanted this constraint, it seems unlikely they would have just forgotten to put it in the set of procedures.
- There is special case text that says if the AF subfield is 0, the remote endpoint is inferred from the NH. “The exception proves the rule."

Furthermore, the first two paragraphs of section 9, while they don’t explicitly say a third-party route is being used, only make sense in that context, so that’s yet more evidence that this is the correct reading. Finally, the first paragraph of the Security section has the same implication.


     *

Can a node R send Tunnel-Encap update with “remote endpoint” being A?

Based on the above, my answer would be “yes”. (Subject to the various validation procedures listed in the draft, of course.)


The Section 13 suggests “BGP Origin Validation [RFC6811] can be used”.  But “BGP Origin Validation” is only to validate the Speaker, correct?

No. The TL;DR of RFC 6811 is that

- There’s a database (the RPKI) that lists (in a cryptographically secure way) what ASes are allowed to originate what prefixes
- A router can check a route against that database, considering the prefix and origin AS:
- If they’re found in the RPKI, the route is considered valid
- If no assertion about the prefix is found in the RPKI, the route is considered not found.
- If an assertion is found in the RPKI but it doesn’t match what was found in the update, the route is considered invalid.

You will note this has nothing to do with the speaker that provided the update, it relates only to the contents of the route.

Naturally this is only a quick summary, from memory. If you want authoritative detail you should refer to RFC 6811 itself. It's short and (IMHO :-) readable.


doesn’t seem to address the security scenario being described.

Maybe my description of RFC 6811 helps?

Regards,

—John



Linda

From: John Scudder <[e-mail]<mailto:[e-mail]>>
Sent: Monday, June 10, 2019 5:26 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: Keyur Patel <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

(Still as a WG contributor)

A little bit more on this.

Your comments led me to go look back at the draft’s Security section again. The first paragraph reads


   The Tunnel Encapsulation attribute can cause traffic to be diverted

   from its normal path, especially when the Remote Endpoint sub-TLV is

   used.  This can have serious consequences if the attribute is added

   or modified illegitimately, as it enables traffic to be "hijacked".


This seems like an explicit acknowledgement of the general class of attack you describe.

It might be helpful if you provide a worked example of a specific attack that would succeed against a tunnel-encaps implementation, but would not succeed against a 5512 implementation. I can’t think of one off the top of my head, but you clearly have something in mind.

Thanks,

—John




On Jun 10, 2019, at 6:16 PM, John Scudder <jgs=[e-mail]<mailto:jgs=[e-mail]>> wrote:

(As a WG contributor)

Hi Linda,

I have a question for you — when you say RFC5512 doesn’t allow a third party to inject routes on behalf of a legitimate router, what do you think would prevent it? You mention the endpoint address in the NLRI, but what would prevent the malicious entity you mention for from falsifying it?

Thanks,

—John



On Jun 10, 2019, at 4:47 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:

Keyur,

Thank for the email.
One more question:

  *   Does the “Remote Endpoint” in draft-ietf-idr-tunnel-encaps-12 represent the BGP speaker that originates the update? Or the remote end point that the “Tunnel” is established to?

     *   I have been told two different versions of the answers. I need confirmation from the authors.



Reading through the Section 13 Security Consideration, I don’t think the following questions have been addressed:


  1.  In RFC5512, the BGP speaker indicates the originating Interface address in the NLRI (section 3):


<image001.png>

Questions:


  *   draft-ietf-idr-tunnel-encaps-12  no longer has the BGP speaker originating the update. Is it intended?



If Yes, does it mean that it allows a third party (which could be malicious entity) to inject routes on behalf of a legitimate router (but RFC5512 doesn’t)?


  *   Why add this scenario? If it is a conscious decision, should have some text to explain why and how to mitigate the security threats introduced.



  *   Section 13 suggests using BGP Origin Validation to obtain the additional assurances of the origin AS is valid. But being valid origin AS doesn’t mean the specific flow is supposed to go/come from there.



#Keyur: Section 13 of the draft version 12 describes Security Considerations that should address your security questions. The option is to provide flexibility.


Thank you,

Linda Dunbar

From: Keyur Patel <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, June 08, 2019 3:45 AM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: John Scudder <[e-mail]<mailto:[e-mail]>>
Subject: Re: recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-11

Hi Linda,

Apologies for the delayed response. Responses are inline. #Keyur

From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Date: Thursday, March 28, 2019 at 6:52 AM
To: idr wg <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-11
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Thursday, March 28, 2019 at 6:52 AM

Just want to reiterate my questions and issues I raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-11, to make it easier for the authors to address them in the next revision (I have sent the questions multiple times on the IDR mailing list, but no one responded):


  1.  When a client route can egress multiple egress ports (each with different IP addresses), does the Tunnel-Encap allow multiple “Remote-endpoint” SubTLV to be attached one UPDATE?


#Keyur: Yes. Section 5 of the draft version 12 has a following  text:

<snip>
A Tunnel Encapsulation attribute may contain several TLVs that all
   specify the same tunnel type.  Each TLV should be considered as
   specifying a different tunnel.  Two tunnels of the same type may have
   different Remote Endpoint sub-TLVs, different Encapsulation sub-TLVs,
   etc.  Choosing between two such tunnels is a matter of local policy.
</snip>



  1.  Section 3.1 Page 10: The last paragraph states that if “Remote-Endpoint sub-TLV contains address is valid but not reachable, and the containing TLV is NOT be malformed ..”. Why a address not reachable is considered as “Not Malformed”?


#Keyur: That is because the Remote-Endpoint could become reachable at the later time. Making it malformed would mean that the Remote-Endpoint has to be dropped upon a receipt of the update message (and could never be used).



  1.  In RFC5512, the BGP speaker indicates the originating Interface address in the NLRI (section 3):


<image001.png>

draft-ietf-idr-tunnel-encaps-11  no longer has the BGP speaker originating the update. Is it intended? If Yes, does it mean that it allows a third party (which could be malicious entity) to inject routes on behalf of a legitimate router (but RFC5512 doesn’t)?  Why add this scenario? How to address the security threats introduced? If it is a conscious decision, should have some text to explain why and how to mitigate the security threats introduced.

#Keyur: Section 13 of the draft version 12 describes Security Considerations that should address your security questions. The option is to provide flexibility.

Regards,
Keyur



Thanks, Linda Dunbar

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=ss5r9k8Dew3MPUscEO1GEzNXkyfGpMlZLZUarUnS3Ys&s=_MC-6zg-U8xFzoGxuXaXYA3GVjY7anTiHQ-cuyr9Pfw&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fwww.ietf.org-5Fmailman-5Flistinfo-5Fidr-2526d-253DDwICAg-2526c-253DHAkYuh63rsuhr6Scbfh0UjBXeMK-2Dndb3voDTXcWzoCI-2526r-253DhLt5iDJpw7ukqICc0hoT7A-2526m-253Dss5r9k8Dew3MPUscEO1GEzNXkyfGpMlZLZUarUnS3Ys-2526s-253D-5FMC-2D6zg-2DU8xFzoGxuXaXYA3GVjY7anTiHQ-2Dcuyr9Pfw-2526e-253D-26data-3D02-257C01-257Cldunbar-2540futurewei.com-257C558cd9ab20274720b23f08d6eeb0d3a3-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C0-257C636958840584510820-26sdata-3D9GNDbc02bhbw8UOfAse8BqRvrod7iWKB9YUEeV14Puk-253D-26reserved-3D0&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=1AyoXaxQ9o5lOxtLcCzBDq3kTaurT7x6ysyIoZtY1EU&s=RjpYAaXfR7_XMRuB5AEEoylIyZhm98UlCZMrArLUm_c&e=>