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 <linda.dunbar@huawei.com>
wrote:

> 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:jefftant.ietf@gmail.com]
> *Sent:* Monday, July 09, 2018 3:35 PM
>
> *To:* Linda Dunbar <linda.dunbar@huawei.com>; Eric C Rosen <
> erosen@juniper.net>; idr@ietf.org; 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 ?
>
>
>
> 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 <linda.dunbar@huawei.com>
> *Date: *Monday, July 9, 2018 at 13:28
> *To: *Jeff Tantsura <jefftant.ietf@gmail.com>, Eric C Rosen <
> erosen@juniper.net>, "idr@ietf.org" <idr@ietf.org>, "
> draft-ietf-idr-tunnel-encaps@ietf.org" <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:jefftant.ietf@gmail.com
> <jefftant.ietf@gmail.com>]
> *Sent:* Monday, July 09, 2018 3:25 PM
> *To:* Linda Dunbar <linda.dunbar@huawei.com>; Eric C Rosen <
> erosen@juniper.net>; idr@ietf.org; 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 ?
>
>
>
> 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 <idr-bounces@ietf.org> on behalf of Linda Dunbar <
> linda.dunbar@huawei.com>
> *Date: *Monday, July 9, 2018 at 13:14
> *To: *Eric C Rosen <erosen@juniper.net>, "idr@ietf.org" <idr@ietf.org>, "
> draft-ietf-idr-tunnel-encaps@ietf.org" <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.
>
>
>
> 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:erosen@juniper.net <erosen@juniper.net>]
> *Sent:* Tuesday, July 03, 2018 12:21 PM
> *To:* Linda Dunbar <linda.dunbar@huawei.com>; idr@ietf.org;
> draft-ietf-idr-tunnel-encaps@ietf.org
> *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
> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>