Re: [Last-Call] Last Call: <draft-ietf-bess-bgp-sdwan-usage-19.txt> (BGP Usage for SD-WAN Overlay Networks) to Informational RFC

[Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>]

John,

 

One key SD-WAN scenario involves expanding the existing VPN network by incorporating additional paths from other networks. In this context, the operator can efficiently utilize their primary management channel, initially designed for VPN control for the BGP to control the SD-WAN. Therefore, there is no strict requirement for BGP over TLS. We can remove the mention of BGP over TLS.

 

As Stephen suggested, we can add the following statement in the Security Consideration:

 

In SD-WAN deployments where no secure management channel exists between the SD-WAN controller and the SD-WAN edges, TLS or IPsec can be established between them. This allows for the creation of a secure BGP session over TLS [BGP-OVER-TLS]. However, it's crucial to conduct a thorough analysis to ensure the security of BGP over TLS.

 

What do you think?

 

Thank you,

 

Linda

-----Original Message-----
From: John Scudder <jgs@xxxxxxxxxxx>
Sent: Tuesday, February 6, 2024 11:22 AM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
Cc: last-call@xxxxxxxx; Andrew Alston - IETF <andrew-ietf@xxxxxxxxxxx>; bess-chairs@xxxxxxxx; bess@xxxxxxxx; draft-ietf-bess-bgp-sdwan-usage@xxxxxxxx; matthew.bocci@xxxxxxxxx
Subject: Re: Last Call: <draft-ietf-bess-bgp-sdwan-usage-19.txt> (BGP Usage for SD-WAN Overlay Networks) to Informational RFC

 

Yes, I noticed that, hence “no *IETF* specification”, it’s an individual draft. If the security model of the present spec relies on BGP-over-TLS, maybe a 00 individual contribution isn’t as firm a foundation as you’d like.

 

Of course, I can’t speak for Roman, it’s his DISCUSS, I was just drawing attention to it.

 

—John

 

> On Feb 6, 2024, at 12:12 PM, Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx> wrote:

>

> John,

>

> There is a draft on BGP over TLS:

> https://nam11.safelinks.protection.outlook.com/?url="">

> efense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-w

> irtgen-bgp-tls%2F__%3B!!NEt6yMaO-gk!EMln0MoNjY8Fex0l37MA8JE4Nvpdsho8Kh

> znAatU81RneYnfGVqYueaJT2WggxyJfkcPuhO1uie8yo67KbfHq0s%24&data="">

> 7Clinda.dunbar%40futurewei.com%7Cfe90fdff921d4367586508dc27383f82%7C0f

> ee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638428369756801895%7CUnknown%

> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX

> VCI6Mn0%3D%7C0%7C%7C%7C&sdata=rCtcgwfoWRsSjN0nTx7PkMpr1RY1jZvnuna63i14

> 47A%3D&reserved=0 We are working with the author to enhance the draft.

>

> We will add the reference to BGP over TLS. And remove the BGP over DTLS.

>

> Can those changes address your comments?

>

> Thank you,

> Linda

>

> -----Original Message-----

> From: John Scudder <jgs@xxxxxxxxxxx>

> Sent: Tuesday, February 6, 2024 9:36 AM

> To: last-call@xxxxxxxx

> Cc: Andrew Alston - IETF <andrew-ietf@xxxxxxxxxxx>;

> bess-chairs@xxxxxxxx; bess@xxxxxxxx;

> draft-ietf-bess-bgp-sdwan-usage@xxxxxxxx; matthew.bocci@xxxxxxxxx

> Subject: Re: Last Call: <draft-ietf-bess-bgp-sdwan-usage-19.txt> (BGP

> Usage for SD-WAN Overlay Networks) to Informational RFC

>

> I haven't done a full review of this document, but I did notice that Roman Danyliw balloted DISCUSS on version 15 [1], asking, among other things, "Are there pointers for BGP over DTLS? Over TLS?". This doesn't appear to have been addressed, either in Linda's reply to Roman [2], or in the text of the document. It seems ill-advised to be last calling a document with an unaddressed DISCUSS. For what it's worth, Roman's point seems to me to be on target - as far as I'm aware, there is no IETF specification for BGP over TLS, and I don't expect that there will ever be a specification for BGP over DTLS, given that BGP assumes a stream transport.

>

> $0.02,

>

> -John

>

> [1]

> https://nam11.safelinks.protection.outlook.com/?url="">

> efense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-i

> etf-bess-bgp-sdwan-usage%2Fballot%2F*draft-ietf-bess-bgp-sdwan-usage_r

> oman-danyliw__%3BIw!!NEt6yMaO-gk!EMln0MoNjY8Fex0l37MA8JE4Nvpdsho8KhznA

> atU81RneYnfGVqYueaJT2WggxyJfkcPuhO1uie8yo67tnMhp0o%24&data="">

> inda.dunbar%40futurewei.com%7Cfe90fdff921d4367586508dc27383f82%7C0fee8

> ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638428369756810949%7CUnknown%7CT

> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI

> 6Mn0%3D%7C0%7C%7C%7C&sdata=s%2FferB2%2FcVh%2FZPN%2BuZ4pHJzhTWEHkI4roi1

> b2MIbHSg%3D&reserved=0 [2]

> https://nam11.safelinks.protection.outlook.com/?url="">

> efense.com%2Fv3%2F__https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2F

> bess%2F-AT3GpMR6rr6-ywB5vWD7EbGk0w%2F__%3B!!NEt6yMaO-gk!EMln0MoNjY8Fex

> 0l37MA8JE4Nvpdsho8KhznAatU81RneYnfGVqYueaJT2WggxyJfkcPuhO1uie8yo67ip_V

> fT4%24&data="">

> 86508dc27383f82%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638428369

> 756817021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi

> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Xcm0%2BjB%2F%2FwIJA%

> 2BDBm9DzotKbuw%2Ft9XhGPnV9WBg9W3E%3D&reserved=0

>

>> On Feb 1, 2024, at 11:58 AM, The IESG <iesg-secretary@xxxxxxxx> wrote:

>>

>>

>> The IESG has received a request from the BGP Enabled ServiceS WG

>> (bess) to consider the following document: - 'BGP Usage for SD-WAN Overlay Networks'

>> <draft-ietf-bess-bgp-sdwan-usage-19.txt> as Informational RFC

>>

>> The IESG plans to make a decision in the next few weeks, and solicits

>> final comments on this action. Please send substantive comments to

>> the last-call@xxxxxxxx mailing lists by 2024-02-15. Exceptionally,

>> comments may be sent to iesg@xxxxxxxx instead. In either case, please

>> retain the beginning of the Subject line to allow automated sorting.

>>

>> Abstract

>>

>>

>>  The document discusses the usage and applicability of BGP as the 

>> control plane for multiple SD-WAN scenarios. The document aims to 

>> demonstrate how the BGP-based control plane is used for large-  scale

>> SD-WAN overlay networks with little manual intervention.

>>

>>  SD-WAN edge nodes are commonly interconnected by multiple types of 

>> underlay networks owned and managed by different network  providers.

>>

>>

>>

>>

>> The file can be obtained via

>> https://nam11.safelinks.protection.outlook.com/?url="">

>> defense.com%2Fv3%2F__https%3A%2F%2Furld%2F__%3B!!NEt6yMaO-gk!EMln0MoN

>> jY8Fex0l37MA8JE4Nvpdsho8KhznAatU81RneYnfGVqYueaJT2WggxyJfkcPuhO1uie8y

>> o67G5eRVA0%24&data="">

>> 21d4367586508dc27383f82%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C

>> 638428369756822210%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj

>> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=IkU7mCcgk

>> NaEYW0shKtMbxxOe9JpDU9uet6tl0iU4CQ%3D&reserved=0

>> efense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-

>> i

>> etf-bess-bgp-sdwan-usage%2F__%3B!!NEt6yMaO-gk!E4My2sQFYwfDPTtjIaFd1jp

>> C

>> RXVBB-u6OkgI3yHHnKfSsS4Kc80iA-x0qPn_krxB9c0LBSQsXvI1RN7dGgEtnA%24&dat

>> a

>> =05%7C02%7Clinda.dunbar%40futurewei.com%7C1a3011314c3340c61f4a08dc272

>> 9

>> 9e48%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638428306920978448%

>> 7

>> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik

>> 1

>> haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kzAz9c%2BLozBWwbLB6YBJxN3QsIBU

>> 1

>> Fu%2Bv2BiXF2a6ek%3D&reserved=0

>>

>>

>>

>> No IPR declarations have been submitted directly on this I-D.

>>

>>

>>

>>

>>

>> _______________________________________________

>> IETF-Announce mailing list

>> IETF-Announce@xxxxxxxx

>> https://nam11.safelinks.protection.outlook.com/?url="">

>> defense.com%2Fv3%2F__https%3A%2F%2Furld%2F__%3B!!NEt6yMaO-gk!EMln0MoN

>> jY8Fex0l37MA8JE4Nvpdsho8KhznAatU81RneYnfGVqYueaJT2WggxyJfkcPuhO1uie8y

>> o67G5eRVA0%24&data="">

>> 21d4367586508dc27383f82%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C

>> 638428369756826869%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj

>> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ztLYFfsZa

>> WanW4MWH2yFY9dTWqo1BJIG4wdQKlLUMpA%3D&reserved=0

>> efense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2

>> F

>> ietf-announce__%3B!!NEt6yMaO-gk!E4My2sQFYwfDPTtjIaFd1jpCRXVBB-u6OkgI3

>> y

>> HHnKfSsS4Kc80iA-x0qPn_krxB9c0LBSQsXvI1RN5i_8mwVg%24&data="">

>> n

>> da.dunbar%40futurewei.com%7C1a3011314c3340c61f4a08dc27299e48%7C0fee8f

>> f

>> 2a3b240189c753a1d5591fedc%7C1%7C0%7C638428306920983211%7CUnknown%7CTW

>> F

>> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6

>> M

>> n0%3D%7C0%7C%7C%7C&sdata=Rp1mvl6HqT6OrlmZbcKKnl3GgVLNckjOiojGF%2BDj12

>> I

>> %3D&reserved=0

>

 

 

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call