Linda,
Thanks for your comments. Please refer to my replies inline …
From: Linda Dunbar <linda.dun...@futurewei.com>
Date: Tuesday, May 30, 2023 at 9:36 AM
To: Lukas Krattiger (lkrattig) <lkrattig=40cisco....@dmarc.ietf.org>, Matthew
Bocci (Nokia) <matthew.bo...@nokia.com>, bess-cha...@ietf.org
<bess-cha...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>, draft-sajassi-bess-secure-e...@ietf.org
<draft-sajassi-bess-secure-e...@ietf.org>
Subject: RE: [bess] WG Adoption and IPR poll for
draft-sajassi-bess-secure-evpn-06
I support the WG adoption with the following questions and comments:
* Section 5: How is the IPsec Databases (SPD, SAD, and generating Keying
material for IPsec SAs) different from the traditional IPsec Data Base
generation described in the RFC 4301? Can you please emphasize the differences?
IKE is P2P; whereas, key generation and re-keying describes is this document is
adapted for P2MP BGP signaling. We will emphasize the differences in future
revision.
* Section 8 Second paragraph states that the Device-Controller trust model
is using the peer-to-peer protocol such as IKEv2. If the devices are already
support EVPN, are they already have trust connection to their corresponding
controller? Can TLS be used for Devices to exchange BGP messages with the
controller?
Absolutely. TLS can also be used for devices-controller trust model for
securing the exchange of BGP messages. I will mention that in the next rev.
* - If a SA is required per pair of IP addresses on two separate PEs, why
it is not enough to have the existing ESP tunnel mode encapsulation for the
packet exchanged between the two PEs like the following?
Outer IP header:
+---------------------------+
|protocol = 50(IPsec ESP) |
| src = source-PE |
| dst = dest-PE |
+---------------------------+ < ----------+
|SPI(Security Parameter Idx)| Authenticated
+---------------------------+ |
| sequence number | |
+---------------------------+ <-+ |
| payload IP header: | | |
| src = source-ip | | |
| dst = dest-ip | | |
+---------------------------+ Encrypted |
| TCP header + | | |
~ payload (variable) ~ | |
| | | |
+===========================+ <-+ -------+
| Authentication Data |
+---------------------------+
Is it necessary to have any outer tunnel header (other than the IPsec's ESP
encapsulation) wrapping around the payload?
Ali> I am guessing you are referring to figure 10, “per IP address”. If so,
this is overlay IP address and thus they are defined in context of a VNI which
means we need VxLAN header. Also, for encap consistency, across different level
of granularity, we are keeping VxLAN header. The encap is not cast in stone and
if we can improve efficiency without complicating data-plane processing, then
we should discuss the options.
Cheers,
Ali
*
Thank you very much
Linda
> On May 25, 2023, at 5:35 AM, Matthew Bocci (Nokia)
> <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>> wrote:
>
> Hello,
> This email begins a two-week WG adoption poll for
> draft-sajassi-bess-secure-evpn-06 [1].
> Please review the draft and post any comments to the BESS working group list.
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with IETF
> IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not progress without answers from all the authors and contributors.
> Currently, there is currently no IPR disclosure against this document.
> If you are not listed as an author or a contributor, then please explicitly
> respond only if you are aware of any IPR that has not yet been disclosed in
> conformance with IETF rules.
> This poll for adoption closes on June 9th 2023 Regards, Matthew and
> Stephane [1]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata<https://data/>
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-sajassi-bess-secure-evpn&data=05
> %7C01%7Clinda.dunbar%40futurewei.com%7Cad6059875d30470c56a908db6117f33
> d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638210527722676515%7CUn
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DwjLIezroZxS%2Fw8vyDe6ypUP3RSGq
> hqOLuLcvsMAkho%3D&reserved=0
> _______________________________________________
> BESS mailing list
> BESS@ietf.org<mailto:BESS@ietf.org>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww<https://www/>.
> ietf.org%2Fmailman%2Flistinfo%2Fbess&data=05%7C01%7Clinda.dunbar%40fut
> urewei.com%7Cad6059875d30470c56a908db6117f33d%7C0fee8ff2a3b240189c753a
> 1d5591fedc%7C1%7C0%7C638210527722676515%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&sdata=WGFVPLLGBKaSYnXDz7ATs1AII8JKBFfBalE7MeIsY7M%3D&reserved=0
_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=05%7C01%7Clinda.dunbar%40futurewei.com%7Cad6059875d30470c56a908db6117f33d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638210527722676515%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WGFVPLLGBKaSYnXDz7ATs1AII8JKBFfBalE7MeIsY7M%3D&reserved=0<https://www.ietf.org/mailman/listinfo/bess>
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
