Re: [Idr] advertising properties of a SD-WAN edge node WAN ports that face untrusted networks, such as the public internet.

[Linda Dunbar <[e-mail]>]

Jun,

Reading through your draft makes me realize that you are not using BGP to propagate IKEv2, correct? i.e. IPsec's IKEv2 still uses traditional plain IKEv2 between two points.

Your draft is suggesting using TUNNEL-ENCAP to advertise a route can be sent through an IPsec SA, in the same way PE advertise VXLAN tunnel for a route to remote nodes? Correct?

If my understanding is correct, yes indeed your draft is addressing a different problem space as draft-dunbar-idr-sdwan-port-safi.

Thanks,
Linda

From: Hu, Jun (Nokia - US/Mountain View) [mailto:[e-mail]]
Sent: Wednesday, March 06, 2019 12:32 PM
To: Linda Dunbar <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: advertising properties of a SD-WAN edge node WAN ports that face untrusted networks, such as the public internet.

Yes, I am aware of them, but as I said, my draft really is not try to be SDN/controller approach:
-        I am not comfortable with the idea of having a central controller to deeply involved in key management; I believe key management should be peer to peer directly (e.g. using protocol like IKEv2)
-        I also believe there is use case where people doesn't want to or can not move to a SDN type network, and my draft provides a solution for that

From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, March 6, 2019 10:20 AM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: advertising properties of a SD-WAN edge node WAN ports that face untrusted networks, such as the public internet.

Jun,

For managing large number of IPsec, there are already work in Security Area (which has gone through violent discussion for last year):

https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/
https://datatracker.ietf.org/doc/draft-carrel-ipsecme-controller-ike/

Linda

From: Hu, Jun (Nokia - US/Mountain View) [mailto:[e-mail]]
Sent: Wednesday, March 06, 2019 12:09 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: advertising properties of a SD-WAN edge node WAN ports that face untrusted networks, such as the public internet.

Sure, we could have discussion, and I have requested a slot to present my draft in idr session
Although I want to make it clear is that my draft doesn't intend to be a SDWAN solution for IPsec, and the intension is to address problem of pre-provision and managing large number of mesh IPsec tunnels, while keep changes limited:
*        no change on how IPsec is implemented (e.g. still uses IKEv2 to create SA)
*        only introduces extensions based on another existing idr draft (ietf-idr-tunnel-encaps)

From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, March 6, 2019 7:55 AM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: advertising properties of a SD-WAN edge node WAN ports that face untrusted networks, such as the public internet.

Jun and IDR group,

We also submitted a draft for using BGP to propagate SDWAN WAN ports properties (including IPsec properties). Hope we can discuss more in IETF 104 to find a common ground.

https://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-port-safi/

Abstract
The document specifies a new BGP NLRI and SAFI for advertising properties of a SD-WAN edge node WAN ports that face untrusted networks, such as the public internet. Those WAN ports may get assigned IP addresses from the Internet Service Providers (ISPs), may get assigned dynamic IP addresses via DHCP, or may have private addresses (e.g. inside third party Cloud DCs). Packets sent over those SDWAN WAN ports might need to be encrypted (depending on the user policies) or need to go through NAT. SD-WAN edge need to propagate those WAN ports properties to its SDWAN controller, which propagates to the authorized peers and manage the IPsec SAs among those peers for encrypting traffic via the untrusted networks.
BGP Route Reflectors (RR) are proposed as points of combination for this information in order to allow scaling of the SDWAN.


Linda Dunbar


From: Idr [mailto:[e-mail]] On Behalf Of Hu, Jun (Nokia - US/Mountain View)
Sent: Tuesday, March 05, 2019 9:42 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [Idr] draft-hujun-idr-bgp-ipsec-00

Hi,
I submitted following draft:

URL:            https://www.ietf.org/internet-drafts/draft-hujun-idr-bgp-ipsec-00.txt

Htmlized:       https://tools.ietf.org/html/draft-hujun-idr-bgp-ipsec-00


This document defines a method of using BGP to signal IPsec tunnel configuration along with NLRI, it uses and extends tunnel encapsulation attribute as specified in [I-D.ietf-idr-tunnel-encaps<https://tools.ietf.org/html/draft-hujun-idr-bgp-ipsec-00#ref-I-D.ietf-idr-tunnel-encaps>] for IPsec tunnel.

Review and comments are greatly appreciated!

Thanks
---------
Hu Jun, ION Nokia