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

From: Linda Dunbar <[email-masked]>
Date: Mon, 10 Jun 2019 20:47:55 +0000

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):

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 <[email-masked]>
Sent: Saturday, June 08, 2019 3:45 AM
To: Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]
Cc: John Scudder <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 28, 2019 at 6:52 AM
To: idr wg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-11
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
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):

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

---

From: John Scudder <[email-masked]>
Date: Mon, 10 Jun 2019 22:16:41 +0000

(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 falsifying it?

Thanks,

—John

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

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

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

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

---

From: John Scudder <[email-masked]>
Date: Mon, 10 Jun 2019 22:26:11 +0000

(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=[email-masked]<mailto:jgs=[email-masked]>> 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

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
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=

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 11 Jun 2019 03:41:31 +0000

John,

You raised a good point.

In RFC5512, the BGP speaker indicates the originating Interface address in the NLRI. I would imagine the receiver can validate the information.

the draft-ietf-idr-tunnel-encaps-12 doesn’t have the information, is it correct?

Linda

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

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

---

From: John Scudder <[email-masked]>
Date: Tue, 11 Jun 2019 14:37:27 +0000

(Still as a WG contributor!)

On Jun 10, 2019, at 11:41 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

John,

You raised a good point.

But if you are concerned about a “malicious entity” why wouldn’t that entity just falsify the originating interface address in the NLRI? So how much genuine security does the validation provide?

I believe so (though I would like one of the authors to confirm).

—John

Linda

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

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 11 Jun 2019 20:41:36 +0000

John,

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

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

The Section 13 suggests “BGP Origin Validation [RFC6811] can be used”.  But “BGP Origin Validation” is only to validate the Speaker, correct?  doesn’t seem to address the security scenario being described.

Linda

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

Thanks,

—John

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

---

From: John Scudder <[email-masked]>
Date: Tue, 11 Jun 2019 21:07:28 +0000

(Still as a WG contributor…)

Hi Linda,

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

John,

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.

     *

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

Thanks,

—John

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 11 Jun 2019 21:50:22 +0000

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.

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?

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.

How does RFC6811 handle this issue?

Linda

Sent: Tuesday, June 11, 2019 4:07 PM

Hi Linda,

John,

     *

Regards,

—John

Linda

Thanks,

—John

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_idr%26d%3DDwICAg%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DhLt5iDJpw7ukqICc0hoT7A%26m%3Dss5r9k8Dew3MPUscEO1GEzNXkyfGpMlZLZUarUnS3Ys%26s%3D_MC-6zg-U8xFzoGxuXaXYA3GVjY7anTiHQ-cuyr9Pfw%26e%3D&data=02%7C01%7Cldunbar%40futurewei.com%7C558cd9ab20274720b23f08d6eeb0d3a3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636958840584510820&sdata=9GNDbc02bhbw8UOfAse8BqRvrod7iWKB9YUEeV14Puk%3D&reserved=0>

---

From: John Scudder <[email-masked]>
Date: Wed, 12 Jun 2019 01:06:22 +0000

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

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

John,

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

That matches my understanding.

Again, that is my understanding.

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

Hi Linda,

John,

     *

Regards,

—John

Linda

Thanks,

—John

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
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=>

---

From: Keyur Patel <[email-masked]>
Date: Wed, 12 Jun 2019 04:29:02 +0000

My comments are inlined #Keyur

From: John Scudder <[email-masked]>
Date: Tuesday, June 11, 2019 at 2:07 PM
To: Linda Dunbar <[email-masked]>
Cc: Keyur Patel <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
Resent-From: <[email-masked]>

Hi Linda,

John,

#Keyur: Completely agree. Remote Endpoint is clearly not constrained to represent only the BGP speaker.

Regards,
Keyur

     *

Regards,

—John

Linda

Thanks,

—John

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

---

From: Keyur Patel <[email-masked]>
Date: Wed, 12 Jun 2019 04:36:33 +0000

Date: Tuesday, June 11, 2019 at 6:06 PM

John,

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.

#Keyur: Ack. Agree.

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.

#Keyur: I would argue if any tunnel encaps could be more secure with RFC6811  + BGPSec as oppose to RFC5512 where rfc6811 and BGPSec application is unclear. That is exactly the reason why I thought your security  related questions were best addressed by section 13 of the draft.

Regards,
Keyur

Regards,

—John

Linda

Hi Linda,

John,

     *

Regards,

—John

Linda

Thanks,

—John

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

---

From: Keyur Patel <[email-masked]>
Date: Wed, 12 Jun 2019 04:40:57 +0000

My comments are inline #Keyur

Date: Tuesday, June 11, 2019 at 7:37 AM

John,

You raised a good point.

#Keyur: That is correct (and agree with John’s observation).

Regards,
Keyur

—John

Linda

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Jun 2019 12:07:03 +0200

Hey,

> #Keyur: Completely agree. Remote Endpoint is clearly not constrained to
represent only the BGP speaker.

That is not the question here.

Draft is really not clear in its current state to define what or who the
"remote endpoint" is. See there are two endpoints and each is the remote
for the other :).

See I have two BGP speakers: A----B

If A sends an update to B with field of "remote endpoint" does this field
apply to A or B ? Is it remote from sender perspective or receiver
perspective of BGP update. That is the dilemma here.

So I agree with Linda that it is in our common interest to define it well
before final publication.

And I do not share John's point that this falls into "rough consensus"
category if he, Linda, Jun and me and I am sure bunch of other folks
reading it while trying to implement will also be unclear. To me it rather
falls into - "insufficient review" bucket.

Thx,
R.

On Wed, Jun 12, 2019 at 6:29 AM Keyur Patel <[email-masked]> wrote:

> *From: *John Scudder <[email-masked]>
> *Date: *Tuesday, June 11, 2019 at 2:07 PM
> *To: *Linda Dunbar <[email-masked]>
> *Cc: *Keyur Patel <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [Idr] recap my questions and issues raised during IDR
> Thurs session for draft-ietf-idr-tunnel-encaps-12
> *Resent-From: *<[email-masked]>
>
>
>
> On Jun 11, 2019, at 4:41 PM, Linda Dunbar <[email-masked]> wrote:
>
>
>
> John,
>
>
>
>    - 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.
>
>
>
>
>    -
>
> 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?
>
>
>
> - There’s a database (the RPKI) that lists (in a cryptographically secure
> way) what ASes are allowed to originate what prefixes
>
> - 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.
>
>
>
> *From:* John Scudder <[email-masked]>
> *Sent:* Monday, June 10, 2019 5:26 PM
> *To:* Linda Dunbar <[email-masked]>
> *Cc:* Keyur Patel <[email-masked]>;
> [email-masked]; [email-masked]
> *Subject:* Re: [Idr] recap my questions and issues raised during IDR
> Thurs session for draft-ietf-idr-tunnel-encaps-12
>
>
>
> 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=[email-masked]> 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 <[email-masked]> 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.
>
>
>
>
>
>    - 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 <[email-masked]>
> *Sent:* Saturday, June 08, 2019 3:45 AM
> *To:* Linda Dunbar <[email-masked]>;
> [email-masked]; [email-masked]
> *Cc:* John Scudder <[email-masked]>
> *Subject:* Re: recap my questions and issues raised during IDR Thurs
> session for draft-ietf-idr-tunnel-encaps-11
>
>
>
> Hi Linda,
>
>
>
> *From: *Linda Dunbar <[email-masked]>
> *Date: *Thursday, March 28, 2019 at 6:52 AM
> *To: *idr wg <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *recap my questions and issues raised during IDR Thurs session
> for draft-ietf-idr-tunnel-encaps-11
> *Resent-From: *<[email-masked]>
> *Resent-To: *<[email-masked]>, <[email-masked]>, <
> [email-masked]>
> *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?
>
>
>
>    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).
>
>
>
>
>
> 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
>
>
>
> [email-masked]
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: John Scudder <[email-masked]>
Date: Wed, 12 Jun 2019 13:50:14 +0000

(As an individual contributor)

On Jun 12, 2019, at 6:07 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

If A sends an update to B with field of "remote endpoint" does this field apply to A or B ? Is it remote from sender perspective or receiver perspective of BGP update. That is the dilemma here.

If you read section 1.1 you’ll see (emphasis added):

   In this scenario, when R1 transmits packet P, it should transmit it
   to R2 through one of the tunnels specified in U's Tunnel
   Encapsulation attribute.  The IP address of the remote endpoint of
   each such tunnel is R2.  Packet P is known as the tunnel's "payload".

That seems to leave nothing to the imagination. But wait you might say, that describes RFC 5512, how am I supposed to know tunnel-encaps has not reversed the definition? For that, we can take a look at section 5, "Semantics and Usage of the Tunnel Encapsulation attribute”, which is exactly where I as a reader would go look to find the semantics and usage, before I decided to complain they were not clear. The bulleted list in that section leaves no room for doubt as to whether the field applies to A or B: it applies to B.

So, as a reader, who is looking for clarity and not for things to complain about, I think the document is clear.

(As a co-chair)

Despite what the individual contributor said above, if the authors desire to add a short definition of “Remote Endpoint” to address these complaints, I wouldn’t have a problem with that and don’t think it would require another last call period.

Regards,

—John

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 12 Jun 2019 15:54:18 +0000

John and authors:

The Section 1.1 says that if R1 sends packets to R2, the remote endpoint of such tunnel is R2. Of course, from R1’s perspective, R2 is the remote endpoint.
But when R2 composes a Tunnel-Encap Update, it is not obvious and not intuitive at all that R2 needs to call itself “remote”. That is where the confusion is. I have raised this question back in -10 version, repeated the question on IDR mailing list, but no one answered.

Many thanks to John responding to my questions. Those emails have helped me to understand the intent of the draft. But I am sure that many implementors who don’t participate in this discussion and future new people coming to IDR will be confused as I was. No wonder it is so hard for any new people to participate/contribute to IDR.

Simply put, this draft is to announce a node’s tunnel encapsulation capabilities (either by its own, or by a third party), Correct?

It will be very helpful to implementors, who are not participating in the discussion today, to add this one sentence to the beginning of Section 3.1:

Remote Endpoint is from receivers’ perspective. When an endpoint A announces its tunnel encapsulation capabilities, it put its own address in the “Remote Endpoint” sub-TLV.

It will be even more helpful to add this sentence to the Abstract and Introduction:
This draft is to announce an endpoint’s (a node or an interface)  tunnel encapsulation capabilities (either by its own, or by a third party), so that receivers can establish appropriate tunnels to this endpoint.

Thank you very much.

Linda

From: John Scudder <[email-masked]>
Sent: Wednesday, June 12, 2019 8:50 AM
To: Robert Raszuk <[email-masked]>
Cc: Keyur Patel <[email-masked]>; Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

(As a co-chair)

Regards,

—John

---

From: Keyur Patel <[email-masked]>
Date: Wed, 12 Jun 2019 16:34:41 +0000

My comments are inlined #Keyur1

From: Robert Raszuk <[email-masked]>
Date: Wednesday, June 12, 2019 at 3:07 AM
To: Keyur Patel <[email-masked]>
Cc: John Scudder <[email-masked]>, Linda Dunbar <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
Resent-From: <[email-masked]>

Hey,

Draft is really not clear in its current state to define what or who the "remote endpoint" is. See there are two endpoints and each is the remote for the other :).

#Keyur1: In this specific example assuming A originated the route and remote endpoint, then it is from B’s perspective. It is the endpoint address to which the tunnel is established.

Regards,
Keyur

So I agree with Linda that it is in our common interest to define it well before final publication.

And I do not share John's point that this falls into "rough consensus" category if he, Linda, Jun and me and I am sure bunch of other folks reading it while trying to implement will also be unclear. To me it rather falls into - "insufficient review" bucket.

Thx,
R.

On Wed, Jun 12, 2019 at 6:29 AM Keyur Patel <[email-masked]<mailto:[email-masked]>> wrote:
My comments are inlined #Keyur

Cc: Keyur Patel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Hi Linda,

John,

Regards,
Keyur

     *

Regards,

—John

Linda

Thanks,

—John

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Jun 2019 18:50:28 +0200

Hi,

So when A is creating the update to be send to B for A the meaning of the
sub-TLV is really a "local tunnel endpoint".

When the update is received at B the same very field in the sub-TLV now
becomes the tunnel destination so it indeed is a  "remote tunnel endpoint".

And then when such update is injected by say third party (for example
controller) neither of this applies when the update is being created.

Therefor why not to simply call the field as "tunnel endpoint address" ?
The "remote" word seems to be only generating confusion here.

To add to this let's observe that the tunnel will be bi-direction in vast
majority of cases. So the same field now when stored in the OS means
different things depending if this is a locally configured/originated value
to be send to a peer(s) or remote value learned from the peer(s).

And it is a bit unfortunate but the word "remote" is heavily used in the
document today. IMO use of remote should always be associated with the
reference of from who's perspective it is to be "remote"

Thx,
R.

On Wed, Jun 12, 2019 at 6:34 PM Keyur Patel <[email-masked]> wrote:

> *From: *Robert Raszuk <[email-masked]>
> *Date: *Wednesday, June 12, 2019 at 3:07 AM
> *To: *Keyur Patel <[email-masked]>
> *Cc: *John Scudder <[email-masked]>, Linda Dunbar <[email-masked]>,
> "[email-masked]" <[email-masked]>, "[email-masked]" <
> #Keyur1: In this specific example assuming A originated the route and
> remote endpoint, then it is from B’s perspective. It is the endpoint
> address to which the tunnel is established.
>
>
>
> Regards,
>
> Keyur
>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 12 Jun 2019 16:56:30 +0000

Agree with Robert!

RFC5512 has “Endpoint Address” TLV, which is so much clearer and more intuitive.  If the Tunnel-Encap needs to keep the “Remote Endpoint” sub-TLV,  suggest adding this one sentence to the beginning of Section 3.1:

Linda

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, June 12, 2019 11:50 AM
To: Keyur Patel <[email-masked]>
Cc: John Scudder <[email-masked]>; Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

Hi,

So when A is creating the update to be send to B for A the meaning of the sub-TLV is really a "local tunnel endpoint".

When the update is received at B the same very field in the sub-TLV now becomes the tunnel destination so it indeed is a  "remote tunnel endpoint".

And then when such update is injected by say third party (for example controller) neither of this applies when the update is being created.

Therefor why not to simply call the field as "tunnel endpoint address" ? The "remote" word seems to be only generating confusion here.

To add to this let's observe that the tunnel will be bi-direction in vast majority of cases. So the same field now when stored in the OS means different things depending if this is a locally configured/originated value to be send to a peer(s) or remote value learned from the peer(s).

And it is a bit unfortunate but the word "remote" is heavily used in the document today. IMO use of remote should always be associated with the reference of from who's perspective it is to be "remote"

Thx,
R.

On Wed, Jun 12, 2019 at 6:34 PM Keyur Patel <[email-masked]<mailto:[email-masked]>> wrote:
My comments are inlined #Keyur1

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 12, 2019 at 3:07 AM
To: Keyur Patel <[email-masked]<mailto:[email-masked]>>
Cc: John Scudder <[email-masked]<mailto:[email-masked]>>, Linda Dunbar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
Resent-From: <[email-masked]<mailto:[email-masked]>>

Hey,

Regards,
Keyur

Thx,
R.

Hi Linda,

John,

Regards,
Keyur

     *

Regards,

—John

Linda

Thanks,

—John

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_idr%26d%3DDwICAg%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DhLt5iDJpw7ukqICc0hoT7A%26m%3Dss5r9k8Dew3MPUscEO1GEzNXkyfGpMlZLZUarUnS3Ys%26s%3D_MC-6zg-U8xFzoGxuXaXYA3GVjY7anTiHQ-cuyr9Pfw%26e%3D&data=02%7C01%7Cldunbar%40futurewei.com%7Ce2945f5e75cf4149c1c608d6ef561c4d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636959550464529871&sdata=ghzr9e6PaDmGKSi9LduqWpLxtccG7Xi0gmT%2BFv11FQY%3D&reserved=0>

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Cldunbar%40futurewei.com%7Ce2945f5e75cf4149c1c608d6ef561c4d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636959550464529871&sdata=0br6KELgkZZcCToRRyG2F1hH17QCetkZmXbn%2Fn1lQsg%3D&reserved=0>

---

From: Keyur Patel <[email-masked]>
Date: Wed, 12 Jun 2019 16:58:31 +0000

Hi Linda,

My comments inlined #Keyur

From: Linda Dunbar <[email-masked]>
Date: Wednesday, June 12, 2019 at 8:54 AM
To: John Scudder <[email-masked]>, Robert Raszuk <[email-masked]>
Cc: Keyur Patel <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
Resent-From: <[email-masked]>

John and authors:

#Keyur: Hopefully this has been clarified.

#Keyur: And the tunnel endpoint address (minimally. Abstract has it covered).

#Keyur: Super. Thanks! As a FYI: There is a text that is in Abstract section 1.2 and section 1.3 which says what you have said and I quote them.

Abstract
<snip>
This document adds support for additional
   tunnel types, and allows a remote tunnel endpoint address to be
   specified for each tunnel.

</snip>

Section 1.2
<snip>
There is no way to use the Tunnel Encapsulation attribute to
      specify the remote endpoint address of a given tunnel; [RFC5512]
      assumes that the remote endpoint of each tunnel is specified as
      the NLRI of an UPDATE of the Encapsulation-SAFI.
</snip>

Section 1.3
<snip>
Defining a new "Remote Endpoint Address sub-TLV" that can be
      included in any of the TLVs contained in the Tunnel Encapsulation
      attribute.  This sub-TLV can be used to specify the remote
      endpoint address of a particular tunnel.

</snip>
Regards,
Keyur

Thank you very much.

Linda

(As a co-chair)

Regards,

—John

---

From: Keyur Patel <[email-masked]>
Date: Wed, 12 Jun 2019 17:01:32 +0000

My comment are inlined #Keyur2

Date: Wednesday, June 12, 2019 at 9:50 AM

Hi,

#Keyur: It is still a remote end-point. 😊  for B receiving a route from a controller. It just turns out that endpoint is not located on controller but on A (still and endpoint).

Regards,
Keyur

Thx,
R.

Hey,

Regards,
Keyur

Thx,
R.

Hi Linda,

John,

Regards,
Keyur

     *

Regards,

—John

Linda

Thanks,

—John

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

---

From: Keyur Patel <[email-masked]>
Date: Wed, 12 Jun 2019 17:11:32 +0000

Opps apologies. One more time. Comments inlined #Keyur3

Date: Wednesday, June 12, 2019 at 10:01 AM

Hi,

#Keyur3: It is still a remote end-point 😊  for B receiving a route from a controller. It just turns out that the endpoint is not located on the controller. It is located on router A (still an endpoint).

Regards,
Keyur

Thx,
R.

Hey,

Regards,
Keyur

Thx,
R.

Hi Linda,

John,

Regards,
Keyur

     *

Regards,

—John

Linda

Thanks,

—John

(As a WG contributor)

Hi Linda,

Thanks,

—John

Keyur,

Thank for the email.
One more question:

Questions:

Thank you,

Linda Dunbar

Hi Linda,

<snip>

Regards,
Keyur

Thanks, Linda Dunbar

---

From: John Scudder <[email-masked]>
Date: Wed, 12 Jun 2019 17:15:38 +0000

(As a contributor)

I guess the disconnect arises from how each reader parses “remote”. To me, and I guess other reviewers who also didn’t notice a problem, it is self-evident that “remote” means “the other end of the tunnel from the point of view of the router encapsulating the packet”. This conversation makes it clear that’s not the only possible reading. As mentioned earlier, I would have no objection to clarifying that point.

—John

On Jun 12, 2019, at 12:58 PM, Keyur Patel <[email-masked]<mailto:[email-masked]>> wrote:

Hi Linda,

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 12, 2019 at 8:54 AM
To: John Scudder <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Keyur Patel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
Resent-From: <[email-masked]<mailto:[email-masked]>>

John and authors:

Abstract
<snip>

</snip>

Section 1.2
<snip>

Section 1.3
<snip>

</snip>
Regards,
Keyur

Thank you very much.

Linda

From: John Scudder <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 12, 2019 8:50 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Keyur Patel <[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

(As a co-chair)

Regards,

—John

---

From: Srihari Sangli <[email-masked]>
Date: Wed, 12 Jun 2019 17:33:23 +0000

(As a contributor)

Srihari> Yes, that’s correct interpretation. “Remote” was referred from Tunnel endpoint perspective. thanks

—John

---

From: Keyur Patel <[email-masked]>
Date: Wed, 12 Jun 2019 17:56:09 +0000

Hi John, all

To that point, I am ok with putting in a text that clarifies a  definition of a remote end-point address. What I like to do is provide a flexibility on what that address can be so it can be inserted by controllers (within the same administrative domain).

Please provide a short text describing the endpoint definition and would be happy to incorporate. 😊

Otherwise here is the suggested text for section3.1: “The Remote Endpoint Sub-TLV”:
Instead of:
3.  an address sub-field, whose length depends upon the Address
       Family.
Maybe:
3.  an address sub-field, whose length depends upon the Address
       Family. This is a remote endpoint address for the tunnel. Receiving BGP speaker of this sub-TLV MUST use this address to establish the tunnel.

Regards,
Keyur

From: John Scudder <[email-masked]>
Date: Wednesday, June 12, 2019 at 10:15 AM
To: Keyur Patel <[email-masked]>
Cc: Linda Dunbar <[email-masked]>, Robert Raszuk <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
Resent-From: <[email-masked]>

(As a contributor)

—John

Hi Linda,

John and authors:

Abstract
<snip>

</snip>

Section 1.2
<snip>

Section 1.3
<snip>

</snip>
Regards,
Keyur

Thank you very much.

Linda

(As a co-chair)

Regards,

—John

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 12 Jun 2019 21:25:08 +0000

All,
It occurred to me that “Remote Endpoint Sub-TLV” is somewhat of a misnomer and perhaps there would be less confusion if this were referred to as the “Tunnel Endpoint Sub-TLV”.
Thanks,
Acee

From: Idr <[email-masked]> on behalf of Keyur Patel <[email-masked]>
Date: Wednesday, June 12, 2019 at 1:57 PM
To: John Scudder <[email-masked]>
Cc: IDR List <[email-masked]>, "[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

Hi John, all

Regards,
Keyur

(As a contributor)

—John

Hi Linda,

John and authors:

Abstract
<snip>

</snip>

Section 1.2
<snip>

Section 1.3
<snip>

</snip>
Regards,
Keyur

Thank you very much.

Linda

(As a co-chair)

Regards,

—John

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 13 Jun 2019 10:35:52 +0800

+1

Xiaohu

------------------------------------------------------------------
From:Acee Lindem (acee) <[email-masked]>
Send Time:2019年6月13日(星期四) 05:25
To:Keyur Patel <[email-masked]>; John Scudder <[email-masked]>
Cc:[email-masked] <[email-masked]>; [email-masked] <[email-masked]>; Robert Raszuk <[email-masked]>
Subject:Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

All,

Please provide a short text describing the endpoint definition and would be happy to incorporate. 

Regards,
Keyur

On Jun 12, 2019, at 12:58 PM, Keyur Patel <[email-masked]> wrote:
Hi Linda,

On Jun 12, 2019, at 6:07 AM, Robert Raszuk <[email-masked]> wrote:

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 13 Jun 2019 08:02:30 +0000

Hi,

Agree it is better to clarify the term “Remote Endpoint Sub-TLV” to avoid the possible confusion. In case people argue that a tunnel has two endpoints, maybe could call it “Tunnel Destination (Endpoint) sub-TLV”?

Best regards,
Jie

From: Idr [mailto:[email-masked]] On Behalf Of 徐小虎(义先)
Sent: Thursday, June 13, 2019 10:36 AM
To: Idr <[email-masked]>; Keyur Patel <[email-masked]>; John Scudder <[email-masked]>
Cc: [email-masked]; [email-masked]; Robert Raszuk <[email-masked]>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

+1

Xiaohu

------------------------------------------------------------------
From:Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Send Time:2019年6月13日(星期四) 05:25
To:Keyur Patel <[email-masked]<mailto:[email-masked]>>; John Scudder <[email-masked]<mailto:[email-masked]>>
Cc:[email-masked] <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Subject:Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

All,

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Keyur Patel <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 12, 2019 at 1:57 PM
To: John Scudder <[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

Hi John, all

Regards,
Keyur

Cc: Linda Dunbar <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

(As a contributor)

—John

Hi Linda,

John and authors:

Abstract
<snip>

</snip>

Section 1.2
<snip>

Section 1.3
<snip>

</snip>
Regards,
Keyur

Thank you very much.

Linda

(As a co-chair)

Regards,

—John