Subject: Re: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

From: Jeff Tantsura <[email-masked]>
Date: Mon, 09 Jul 2018 13:24:33 -0700

Hi Linda,

Why would you want to build what you are trying to do into protocol?

#1 local policy

#2  NO_ADVERTISE does that exactly 

Cheers,

Jeff

From: Idr <[email-masked]> on behalf of Linda Dunbar <[email-masked]>
Date: Monday, July 9, 2018 at 13:14
To: Eric C Rosen <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Eric, 

draft-ietf-idr-tunnel-encaps-09 discussed ways to resolve conflicts of multiple UPDATE messages with Tunnel Encap attributes. 

Is it possible to have following capability? 
Have a bit indicating a specific UPDATE is from authoritative source, therefore overwrite all other Tunnel Attributes for the Prefix X to avoid recursive next hop issues and tunnel selection at the receiving Router? 
Have a bit indicating that a specific UPDATE only contain Tunnel attributes for the receiving Router, therefore can’t be forwarded? 

You said that SAFI 7 is deprecated because no one seemed interested in using it. We are very interested in using it because 
it can be easily distinguished from normal  BGP UPDATE
 The receiving router doesn’t have to “Filter” the tunnel attributes before forwarding to others.  
Can even be used for passing reconfigured IPsec keys to two ends of a tunnel. 

Therefore we think SAFI 7 should be reserved. 

Thanks, Linda Dunbar

From: Eric C Rosen [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2018 12:21 PM
To: Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: What are side effect for having Encap SAFI? can draft-ietf-idr-tunnel-encaps-09 preserve trigger tunnel creation before VPN is established?

On 7/2/2018 6:31 PM, Linda Dunbar wrote:

Eric, IDR group, 

It is indicated that RFC5512 is to be replaced by draft-ietf-idr-tunnel-encaps. But draft-ietf-idr-tunnel-encaps-09 stated that it deprecates the

Encapsulation SAFI. 

We find the Encapsulation SAFI is quite useful for CPE based EVPN.  For example, a Controller (say RR) can send an update with Encapsulation SAFI to two end points to trigger a tunnel establishment between them. 

What are side effect for having Encap SAFI? Can we preserve it in draft-ietf-idr-tunnel-encaps?

Thanks, Linda Dunbar

SAFI 7 was deprecated because no one seemed interested in using it, it creates additional operational issues, there is no real need for it, and it was discouraging folks from actually using the Tunnel Encapsulation attribute.  This is discussed briefly in section 1.2 of the draft.

You can get a similar effect by using the technique described in section 7 of the draft.

If PE1 is the egress point of a tunnel, have PE1 originate an UPDATE whose NLRI is PE1's loopback address.  Put the Tunnel Encapsulation attribute (with PE1 as remote endpoint) on this UPDATE.  (The next hop field of this UPDATE doesn't really matter, as long as it is resolvable.)  When PE1 originates VPN routes, it sets the next hop to be its loopback address.  Per section 7, this will result in packets being sent to PE1 though the specified tunnel.

_______________________________________________ Idr mailing list [email-masked] https://www.ietf.org/mailman/listinfo/idr

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Jul 2018 20:28:15 +0000

Jeff,

We would like to use RR as controller to distribute more detailed tunnel information, such as IPsec configuration & keys because in managed large scale Overlay deployment (SD-WAN), it doesn’t scale to allow all CPEs to negotiate IPsec keys.

Linda

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Monday, July 09, 2018 3:25 PM
To: Linda Dunbar <[email-masked]>; Eric C Rosen <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Hi Linda,

Cheers,
Jeff

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 9, 2018 at 13:14
To: Eric C Rosen <[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: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Eric,

Is it possible to have following capability?
-        Have a bit indicating a specific UPDATE is from authoritative source, therefore overwrite all other Tunnel Attributes for the Prefix X to avoid recursive next hop issues and tunnel selection at the receiving Router?
-        Have a bit indicating that a specific UPDATE only contain Tunnel attributes for the receiving Router, therefore can’t be forwarded?

You said that SAFI 7 is deprecated because no one seemed interested in using it. We are very interested in using it because
-        it can be easily distinguished from normal  BGP UPDATE
-         The receiving router doesn’t have to “Filter” the tunnel attributes before forwarding to others.
-        Can even be used for passing reconfigured IPsec keys to two ends of a tunnel.

Thanks, Linda Dunbar

From: Eric C Rosen [mailto:[email-masked]]
Sent: Tuesday, July 03, 2018 12:21 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: What are side effect for having Encap SAFI? can draft-ietf-idr-tunnel-encaps-09 preserve trigger tunnel creation before VPN is established?

Eric, IDR group,

Thanks, Linda Dunbar

_______________________________________________ Idr mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/idr

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 09 Jul 2018 13:34:56 -0700

Linda,

You meant to say – you’d use RR to distribute information injected from and by a controller?

Reflector (as the name suggests) reflects the routes, it doesn’t originates them as part of the reflector functionality  (it for sure could as a BGP speaker if such functionality is collocated with RR)

Please read my initial questions, it looks like what you are trying to achieve could be done with the existing technology.

Thanks!

Cheers,

Jeff

From: Linda Dunbar <[email-masked]>
Date: Monday, July 9, 2018 at 13:28
To: Jeff Tantsura <[email-masked]>, Eric C Rosen <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Jeff, 

Linda

Hi Linda,

#1 local policy

Cheers,

Jeff

Eric, 

Thanks, Linda Dunbar

Eric, IDR group, 

Encapsulation SAFI. 

Thanks, Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Jul 2018 20:50:04 +0000

Jeff,

The answer to your question “Why would you want to build what you are trying to do into protocol?” is

-        We want to use BGP to do more (i.e. use RR to distribute information injected from and by a controller). to eliminate dealing with the changes to NHRP/DSVPN.

Can you elaborate the “the existing technology”?

Linda

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Monday, July 09, 2018 3:35 PM
To: Linda Dunbar <[email-masked]>; Eric C Rosen <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Linda,

Cheers,
Jeff

From: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 9, 2018 at 13:28
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, Eric C Rosen <[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] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Jeff,

Linda

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Monday, July 09, 2018 3:25 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Eric C Rosen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Hi Linda,

Cheers,
Jeff

Eric,

Thanks, Linda Dunbar

Eric, IDR group,

Thanks, Linda Dunbar

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Jul 2018 22:53:32 +0200

Hi Linda,

I think Jeff is asking why not to use well known community to scope the
blast radius of the advertisement.

But personally I think this is pretty weak protection - if this would be
the only protection against IPSec credential's hijack. IMO this needs to be
protected a bit stronger such that even leak of the update will cause no
harm or VPN compromise.

Thx,
R.

On Mon, Jul 9, 2018 at 10:50 PM, Linda Dunbar <[email-masked]>
wrote:

> -        We want to use BGP to do more (i.e. use RR to distribute
> information injected from and by a controller). to eliminate dealing with
> the changes to NHRP/DSVPN.
>
>
>
> *From:* Jeff Tantsura [mailto:[email-masked]]
> *Sent:* Monday, July 09, 2018 3:35 PM
>
> *To:* Linda Dunbar <[email-masked]>; Eric C Rosen <
> [email-masked]>; [email-masked]; [email-masked]
> *Subject:* Re: [Idr] Possible to set up priority for Tunnels established
> by draft-ietf-idr-tunnel-encaps-09 ?
>
>
>
> Linda,
>
>
>
> Reflector (as the name suggests) reflects the routes, it doesn’t
> originates them as part of the reflector functionality  (it for sure could
> as a BGP speaker if such functionality is collocated with RR)
>
>
>
> Please read my initial questions, it looks like what you are trying to
> achieve could be done with the existing technology.
>
> Thanks!
>
>
>
> Cheers,
>
> Jeff
>
>
>
> *From: *Linda Dunbar <[email-masked]>
> *Date: *Monday, July 9, 2018 at 13:28
> *To: *Jeff Tantsura <[email-masked]>, Eric C Rosen <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <draft-ietf-idr-tunnel-encaps@
> ietf.org>
> *Subject: *RE: [Idr] Possible to set up priority for Tunnels established
> by draft-ietf-idr-tunnel-encaps-09 ?
>
>
>
> Jeff,
>
>
>
> We would like to use RR as controller to distribute more detailed tunnel
> information, such as IPsec configuration & keys because in managed large
> scale Overlay deployment (SD-WAN), it doesn’t scale to allow all CPEs to
> negotiate IPsec keys.
>
>
>
> Linda
>
>
>
> *From:* Jeff Tantsura [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Monday, July 09, 2018 3:25 PM
> *To:* Linda Dunbar <[email-masked]>; Eric C Rosen <
> [email-masked]>; [email-masked]; [email-masked]
> *Subject:* Re: [Idr] Possible to set up priority for Tunnels established
> by draft-ietf-idr-tunnel-encaps-09 ?
>
>
>
> Hi Linda,
>
>
>
> *From: *Idr <[email-masked]> on behalf of Linda Dunbar <
> [email-masked]>
> *Date: *Monday, July 9, 2018 at 13:14
> *To: *Eric C Rosen <[email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <draft-ietf-idr-tunnel-encaps@
> ietf.org>
> *Subject: *[Idr] Possible to set up priority for Tunnels established by
> draft-ietf-idr-tunnel-encaps-09 ?
>
>
>
> Eric,
>
>
>
> draft-ietf-idr-tunnel-encaps-09 discussed ways to resolve conflicts of
> multiple UPDATE messages with Tunnel Encap attributes.
>
>
>
> -        Have a bit indicating a specific UPDATE is from authoritative
> source, therefore overwrite all other Tunnel Attributes for the Prefix X to
> avoid recursive next hop issues and tunnel selection at the receiving
> Router?
>
> -        Have a bit indicating that a specific UPDATE only contain Tunnel
> attributes for the receiving Router, therefore can’t be forwarded?
>
>
>
> You said that SAFI 7 is deprecated because no one seemed interested in
> using it. We are very interested in using it because
>
> *From:* Eric C Rosen [mailto:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, July 03, 2018 12:21 PM
> *To:* Linda Dunbar <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: What are side effect for having Encap SAFI? can
> draft-ietf-idr-tunnel-encaps-09 preserve trigger tunnel creation before
> VPN is established?
>
>
>
> It is indicated that RFC5512 is to be replaced by
> draft-ietf-idr-tunnel-encaps. But draft-ietf-idr-tunnel-encaps-09 stated
> that it deprecates the
>
> Encapsulation SAFI.
>
>
>
> We find the Encapsulation SAFI is quite useful for CPE based EVPN.  For
> example, a Controller (say RR) can send an update with Encapsulation SAFI
> to two end points to trigger a tunnel establishment between them.
>
> SAFI 7 was deprecated because no one seemed interested in using it, it
> creates additional operational issues, there is no real need for it, and it
> was discouraging folks from actually using the Tunnel Encapsulation
> attribute.  This is discussed briefly in section 1.2 of the draft.
>
> If PE1 is the egress point of a tunnel, have PE1 originate an UPDATE whose
> NLRI is PE1's loopback address.  Put the Tunnel Encapsulation attribute
> (with PE1 as remote endpoint) on this UPDATE.  (The next hop field of this
> UPDATE doesn't really matter, as long as it is resolvable.)  When PE1
> originates VPN routes, it sets the next hop to be its loopback address.
> Per section 7, this will result in packets being sent to PE1 though the
> specified tunnel.
>
>
>
> _______________________________________________ Idr mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 09 Jul 2018 14:03:42 -0700

Yes Robert, exactly and such I would question the use of BGP (KitchenSinkProtocol) to do so in general

Cheers,

Jeff

From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Monday, July 9, 2018 at 13:53
To: Linda Dunbar <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>, Eric C Rosen <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Hi Linda,

I think Jeff is asking why not to use well known community to scope the blast radius of the advertisement. 

But personally I think this is pretty weak protection - if this would be the only protection against IPSec credential's hijack. IMO this needs to be protected a bit stronger such that even leak of the update will cause no harm or VPN compromise.

Thx,
R.

On Mon, Jul 9, 2018 at 10:50 PM, Linda Dunbar <[email-masked]> wrote:

Jeff, 

Linda

Linda,

Thanks!

Cheers,

Jeff

Jeff, 

Linda

Hi Linda,

#1 local policy

Cheers,

Jeff

Eric, 

Thanks, Linda Dunbar

Eric, IDR group, 

Encapsulation SAFI. 

Thanks, Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Jul 2018 21:05:02 +0000

Eric,

Why not using “NO_ADVERTISE” in the Section 10 of draft-ietf-idr-tunnel-encaps-09?

Linda

Hi Linda,

Cheers,
Jeff

Eric,

Thanks, Linda Dunbar

Eric, IDR group,

Thanks, Linda Dunbar

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Jul 2018 23:09:00 +0200

Hey Jeff,

You know me saying lately that using BGP (aka KSP) is a bad idea if we use
it to distribute p2p information. However here the information is really
p2mp (provided common IPSec credentials are distributed to all CPEs) so it
actually may make sense.

Just started a side thread on this with a little idea how we could do that
safely :)

But if you have a suggestion to use some other protocol for it I am all
ears !

Cheers,
R

On Mon, Jul 9, 2018 at 11:03 PM, Jeff Tantsura <[email-masked]>
wrote:

> Yes Robert, exactly and such I would question the use of BGP
> (KitchenSinkProtocol) to do so in general
>
>
>
> Cheers,
>
> Jeff
>
>
>
> *From: *<[email-masked]> on behalf of Robert Raszuk <[email-masked]>
> *Date: *Monday, July 9, 2018 at 13:53
> *To: *Linda Dunbar <[email-masked]>
> *Cc: *Jeff Tantsura <[email-masked]>, Eric C Rosen <
> *Subject: *Re: [Idr] Possible to set up priority for Tunnels established

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Jul 2018 23:12:32 +0200

Because the NO_ADVERTISE is about the property of the NLRI - entire BGP
UPDATE MSG get's blocked while in section 10 it is about just dropping a
single attribute which happened to be attached to a perhaps still valid
UPDATE MSG.

---

From: Keyur Patel <[email-masked]>
Date: Mon, 9 Jul 2018 21:14:35 +0000

+1.  Exactly what Robert said.

Regards,
Keyur

On Jul 9, 2018, at 2:53 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Linda,

Thx,
R.

On Mon, Jul 9, 2018 at 10:50 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Jeff,

Linda

From: Jeff Tantsura [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, July 09, 2018 3:35 PM

Linda,

Cheers,
Jeff

Jeff,

Linda

Hi Linda,

Cheers,
Jeff

Eric,

Thanks, Linda Dunbar

Eric, IDR group,

Thanks, Linda Dunbar

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Jul 2018 21:20:12 +0000

That is one of the main reason we think it is better to have a dedicated message to pass “Tunnel Encap attributes” instead of appended to the BGP update message.
It is so much easier for CPEs to process an Independent “tunnel attribute” information instead of filtering out which field can/can’t be distribute to others.

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, July 09, 2018 4:13 PM
To: Linda Dunbar <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>; Eric C Rosen <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Because the NO_ADVERTISE is about the property of the NLRI - entire BGP UPDATE MSG get's blocked while in section 10 it is about just dropping a single attribute which happened to be attached to a perhaps still valid UPDATE MSG.

On Mon, Jul 9, 2018 at 11:05 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Eric,

Linda

Hi Linda,

Cheers,
Jeff

Eric,

Thanks, Linda Dunbar

Thanks, Linda Dunbar

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Jul 2018 23:29:22 +0200

IMO both are needed.

The original drivers for tunnel encapsulation attribute clearly proved that
new SAFI is an excessive thing. Please note that in any SAFI you can easily
craft independent BGP MSG without need for separate AFI/SAFI type.

Said this however for the SD-WAN application we are discussing here I would
be actually in favor of separating it from any other BGP use by dedicating
a new AFI/SAFI for it.

Thx,
R.

On Mon, Jul 9, 2018 at 11:20 PM, Linda Dunbar <[email-masked]>
wrote:

> That is one of the main reason we think it is better to have a dedicated
> message to pass “Tunnel Encap attributes” instead of appended to the BGP
> update message.
>
> It is so much easier for CPEs to process an Independent “tunnel attribute”
> information instead of filtering out which field can/can’t be distribute to
> others.
>
>
>
> Linda
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Monday, July 09, 2018 4:13 PM
> *To:* Linda Dunbar <[email-masked]>
> *Cc:* Jeff Tantsura <[email-masked]>; Eric C Rosen <

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Jul 2018 21:34:35 +0000

Thanks Robert’s suggesting of having a new ARI/SAFI for SD-WAN.

An independent SAFI for SD-WAN would make our implementation easier. In addition in SD-WAN deployment the RR and CPE might be connected by TLS/DTLS.

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, July 09, 2018 4:29 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

IMO both are needed.

The original drivers for tunnel encapsulation attribute clearly proved that new SAFI is an excessive thing. Please note that in any SAFI you can easily craft independent BGP MSG without need for separate AFI/SAFI type.

Said this however for the SD-WAN application we are discussing here I would be actually in favor of separating it from any other BGP use by dedicating a new AFI/SAFI for it.

Thx,
R.

On Mon, Jul 9, 2018 at 11:20 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
That is one of the main reason we think it is better to have a dedicated message to pass “Tunnel Encap attributes” instead of appended to the BGP update message.
It is so much easier for CPEs to process an Independent “tunnel attribute” information instead of filtering out which field can/can’t be distribute to others.

Linda

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Monday, July 09, 2018 4:13 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; Eric C Rosen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Linda

Hi Linda,

Cheers,
Jeff

Eric,

Thanks, Linda Dunbar

Thanks, Linda Dunbar

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Jul 2018 23:43:44 +0200

Hi Linda,

In addition to your comment what needs to also be highlighted in bold is
that new SAFI will help the co-existence with number of existing SD-WAN
deployments. Loading currently deployed controllers with any of the
existing unicast SAFIs no matter how well filtered will not be a great idea
operationally.

The point about missing DTLS has been communicated to Eric the same day his
and Ron's draft got posted. It was accepted well :).

Best,
R.

On Mon, Jul 9, 2018 at 11:34 PM, Linda Dunbar <[email-masked]>
wrote:

> An independent SAFI for SD-WAN would make our implementation easier. In
> addition in SD-WAN deployment the RR and CPE might be connected by
> TLS/DTLS.
>
>
>
> Linda
>
>
>
> *Sent:* Monday, July 09, 2018 4:29 PM
> *Cc:* [email-masked]; [email-masked]
>
> The original drivers for tunnel encapsulation attribute clearly proved
> that new SAFI is an excessive thing. Please note that in any SAFI you can
> easily craft independent BGP MSG without need for separate AFI/SAFI type.
>
>
>
> Said this however for the SD-WAN application we are discussing here I
> would be actually in favor of separating it from any other BGP use by
> dedicating a new AFI/SAFI for it.
>
>
>
> Thx,
> R.
>
>
>

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 10 Jul 2018 11:13:05 -0400

On 7/9/2018 4:28 PM, Linda Dunbar wrote:
> We would like to use RR as controller to distribute more detailed 
> tunnel information, such as IPsec configuration & keys because in 
> managed large scale Overlay deployment (SD-WAN), it doesn’t scale to 
> allow all CPEs to negotiate IPsec keys. 

When first working on RFC 5566, I proposed a number of sub-TLVs that 
could be used to convey information about how to set up the IPsec 
Security Associations.  None of thes survived review by the security 
experts.  Setting up the Security Associations is the job of IKEv2. If 
you want to replace IKEv2 with BGP, you'll need a thorough security 
analysis of your proposed mechanism.

One might think it is okay to have BGP UPDATEs carry secret keys , as 
long as the UPDATEs only travel on sessions that are protected by 
IPsec.  I wouldn't necessarily assume that, as BGP UPDATEs have been 
known to leak (intentionally or unintentionally) beyond their intended 
scope.

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 10 Jul 2018 19:56:21 +0000

Eric,

Security area has a Working Group draft on the data model of exchanging IPsec Keys: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/

It was a very lengthy debate on exposing the key via Netconf. Eventually, they (IPsecme group) agreed to ADOPT BUT requiring the authors to document all the associated security risks in the draft. So that people/companies who are willing to take the risks documented in the draft can use them. Maybe we can get pass security expert review afterwards.

We are hoping for a BGP message with a specific SAFI as did in RFC 5512 to carry the information instead of mixing with the BGP UPDATE message, so that receiving CPE doesn’t have to do extra processing, and the msg can be sent via any paths.

Linda

From: Eric C Rosen [mailto:[email-masked]]
Sent: Tuesday, July 10, 2018 10:13 AM
To: Linda Dunbar <[email-masked]>; Jeff Tantsura <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

When first working on RFC 5566, I proposed a number of sub-TLVs that could be used to convey information about how to set up the IPsec Security Associations.  None of thes survived review by the security experts.  Setting up the Security Associations is the job of IKEv2.  If you want to replace IKEv2 with BGP, you'll need a thorough security analysis of your proposed mechanism.

One might think it is okay to have BGP UPDATEs carry secret keys , as long as the UPDATEs only travel on sessions that are protected by IPsec.  I wouldn't necessarily assume that, as BGP UPDATEs have been known to leak (intentionally or unintentionally) beyond their intended scope.