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 <j...@juniper.net>
Sent: Tuesday, February 6, 2024 11:22 AM
To: Linda Dunbar <linda.dun...@futurewei.com>
Cc: last-c...@ietf.org; Andrew Alston - IETF <andrew-i...@liquid.tech>; 
bess-cha...@ietf.org; bess@ietf.org; draft-ietf-bess-bgp-sdwan-us...@ietf.org; 
matthew.bo...@nokia.com
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.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> wrote:
>
> John,
>
> There is a draft on BGP over TLS:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-w
> irtgen-bgp-tls%2F__%3B!!NEt6yMaO-gk!EMln0MoNjY8Fex0l37MA8JE4Nvpdsho8Kh
> znAatU81RneYnfGVqYueaJT2WggxyJfkcPuhO1uie8yo67KbfHq0s%24&data=05%7C02%
> 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 <j...@juniper.net<mailto:j...@juniper.net>>
> Sent: Tuesday, February 6, 2024 9:36 AM
> To: last-c...@ietf.org<mailto:last-c...@ietf.org>
> Cc: Andrew Alston - IETF 
> <andrew-i...@liquid.tech<mailto:andrew-i...@liquid.tech>>;
> bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; 
> bess@ietf.org<mailto:bess@ietf.org>;
> draft-ietf-bess-bgp-sdwan-us...@ietf.org<mailto:draft-ietf-bess-bgp-sdwan-us...@ietf.org>;
>  matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>
> 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=https%3A%2F%2Furld
> 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=05%7C02%7Cl
> 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=https%3A%2F%2Furld
> 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=05%7C02%7Clinda.dunbar%40futurewei.com%7Cfe90fdff921d43675
> 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-secret...@ietf.org<mailto:iesg-secret...@ietf.org>> 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-c...@ietf.org<mailto:last-c...@ietf.org> mailing lists by 
>> 2024-02-15. Exceptionally,
>> comments may be sent to i...@ietf.org<mailto:i...@ietf.org> 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=https%3A%2F%2Furl
>> defense.com%2Fv3%2F__https%3A%2F%2Furld%2F__%3B!!NEt6yMaO-gk!EMln0MoN
>> jY8Fex0l37MA8JE4Nvpdsho8KhznAatU81RneYnfGVqYueaJT2WggxyJfkcPuhO1uie8y
>> o67G5eRVA0%24&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cfe90fdff9
>> 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-annou...@ietf.org<mailto:ietf-annou...@ietf.org>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
>> defense.com%2Fv3%2F__https%3A%2F%2Furld%2F__%3B!!NEt6yMaO-gk!EMln0MoN
>> jY8Fex0l37MA8JE4Nvpdsho8KhznAatU81RneYnfGVqYueaJT2WggxyJfkcPuhO1uie8y
>> o67G5eRVA0%24&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cfe90fdff9
>> 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=05%7C02%7Cli
>> 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
>


_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to