Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt

[Robert Raszuk <[e-mail]>]

John,

> Making the Remote Endpoint sub-TLV mandatory effectively associates the
attribute with the remote endpoint.

I am not sure why you draw such conclusion.

Including remote endpoint address does not bind this sub-TLV to be
advertised with the remote end point NLRI. Quite contrary this information
is needed on a per NLRI basis.

How could you not send endpoint address if the entire purpose of this
extension is to signal the address where the encapsulation should be
terminated at - no ?

Thx,
R.





On Wed, Jun 26, 2019 at 8:27 PM John E Drake <jdrake=
[e-mail]> wrote:

> John,
>
>
>
> Oopsie, I missed that.  Do we really want to have this behavior?  Having
> it optional would give us a lot more flexibility and I thought an attribute
> was supposed to be associated with a route.  Making the Remote Endpoint
> sub-TLV mandatory effectively associates the attribute with the remote
> endpoint.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* John Scudder <[e-mail]>
> *Sent:* Wednesday, June 26, 2019 2:06 PM
> *To:* Linda Dunbar <[e-mail]>; John E Drake <
> [e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [Idr] Tunnel-Encap Gaps for SD-WAN described in
> draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
>
>
>
> Linda, John,
>
>
>
> Your discussion is premised on the assumption that the remote endpoint
> sub-TLV is optional. Consider this paragraph, from section 5:
>
>
>
>    When the Tunnel Encapsulation attribute is carried in an UPDATE of
>
>    one of the AFI/SAFIs specified in the previous paragraph, each TLV
>
>    MUST have a Remote Endpoint sub-TLV.  If a TLV that does not have a
>
>    Remote Endpoint sub-TLV, that TLV should be treated as if it had a
>
>    malformed Remote Endpoint sub-TLV (see Section 3..1 <https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-12#section-3.1>).
>
>
>
> There’s both a MUST clause and directions to ignore the sub-TLV if the
> remote endpoint is missing. To me this seems clear without any changes to
> the draft.
>
>
>
> Regards,
>
>
>
> —John
>
>
>
> On Jun 21, 2019, at 8:25 AM, Linda Dunbar <[e-mail]>
> wrote:
>
>
>
> John,
>
>
>
> I am with you hoping that the Tunnel-encap authors can clarify more.
>
> Based on the description of how the receivers of the Tunnel UPDATE msg add
> the Encapsulation Headers to client routes described in the Tunnel-Encap
> draft, it should be:
>
>    - If the “Remote endpoint” sub-TLV was present and containing the same
>    address as the route itself, then the receivers of the Tunnel UPDATE would
>    construct the encapsulation header with the Outer Destination Address equal
>    to the “route itself” (which is carried in the Remote Endpoint sub-TLV).
>
> I think this can be a serious problem.
>
>
>
>    - if the “Remote Endpoint” sub-TLV was not present, the receivers of
>    the Tunnel UPDATE would assume the UPDATE originator’s address as the
>    Tunnel Remote end point.
>
>
>
> If the processing behavior described above is NOT what the Tunnel-Encap
> draft intended, then the Tunnel-Encap draft needs to add text to clarify
> the description.
>
>
>
> Nevertheless, do you have objections of those gaps that Tunnel-Encap and
> Secure-EVPN:
>
>
>
> - Doesn’t have the functionality that would help the C-PE to register its
> WAN Port properties. Some WAN ports are facing public internet with ISP
> assigned addresses that are in different address space than the SD-WAN
> address space, some WAN ports are assigned with private addresses which
> need to propagate NAT information to the trusted peers via Controllers,
> such as the virtual C-PEs instantiated in public Cloud DCs, and some WAN
> ports are facing the trusted MPLS network.
>
>
>
> - For the same Client route, e.g. 10.1.x.x, attached to a C-PE, need to be
> encrypted when forwarding to the WAN ports facing untrusted network, and
> can be forwarded without any encryption towards WAN ports facing trusted
> network.
>
>
>
>
>
> Thank you very much for the discussion. I have updated the Gap analysis to
> reflect what has been discussed in this email thread...
>
>
>
> Linda
>
>
>
> *From:* John E Drake <[e-mail]>
> *Sent:* Friday, June 21, 2019 8:14 AM
> *To:* Linda Dunbar <[e-mail]>; [e-mail];
> [e-mail]
> *Subject:* RE: Tunnel-Encap Gaps for SD-WAN described in
> draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
>
>
>
> Linda,
>
>
>
> It would be useful to get a clarification from the authors.  I had always
> thought that if the remote endpoint sub-TLV was either not present or
> present and containing the same address as the route itself, then the
> information in the tunnel encapsulation attribute pertains to the address
> specified in the route.  This is the assumption made in the Secure EVPN
> draft that I mentioned earlier in this thread.
>
>
>
> Alternatively, the route could specify a loopback address of the C-PE and
> the tunnel encapsulation attribute could contain the interface address and
> characteristics of each of its WAN-facing ports; this is completely
> compliant with your interpretation that the address specified in the route
> is reachable through an address specified in the remote endpoint sub-TLV.
>
>
>
> [Linda] But there is no field to indicate the property of the WAN ports.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Internal
>
> *From:* Linda Dunbar <[e-mail]>
> *Sent:* Thursday, June 20, 2019 7:08 PM
> *To:* John E Drake <[e-mail]>; [e-mail]; [e-mail]
> *Subject:* RE: Tunnel-Encap Gaps for SD-WAN described in
> draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
>
>
>
> John,
>
>
>
> Those addresses stated in the quoted paragraphs are for Clients Routes,
> i.e. the routes attached to the PE, not the PE’s lookback address, correct?
>
> The Loopback Address is specified in the “Remote Endpoint” SubTLV, so that
> receivers of the UPDATE can establish the Encapsulation with the outer
> destination address equal to the one specified by the “Remote endpoint”
> SubTLV.
>
>
>
> That was discussed in the long email discussion thread last week.
>
>
>
> We can ask the Tunnel-Encap authors to confirm.
>
>
>
> Linda
>
>
>
> *From:* John E Drake <[e-mail]>
> *Sent:* Thursday, June 20, 2019 5:50 PM
> *To:* Linda Dunbar <[e-mail]>; [e-mail];
> [e-mail]
> *Subject:* RE: Tunnel-Encap Gaps for SD-WAN described in
> draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
>
>
>
> Linda,
>
>
>
> From section 5 on the Tunnel Encapsulation Attribute draft:
>
>
>
> “[RFC5512] specifies the use of the Tunnel Encapsulation attribute in
>
> BGP UPDATE messages of AFI/SAFI 1/7 and 2/7.  That document restricts
>
> the use of this attribute to UPDATE messsages of those SAFIs.  This
>
> document removes that restriction.
>
>
>
> The BGP Tunnel Encapsulation attribute MAY be carried in any BGP
>
> UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
>
> Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast),
>
> 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast),
>
> or 25/70 (Ethernet VPN, usually known as EVPN)).  Use of the Tunnel
>
> Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is
>
> outside the scope of this document.”
>
>
>
> What this means is that the tunnel encapsulation draft can be use exactly
>
> as I described in my previous email to describe the characteristics of
>
> of an SD-WAN port.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Internal
>
> *From:* Linda Dunbar <[e-mail]>
> *Sent:* Thursday, June 20, 2019 6:08 PM
> *To:* John E Drake <[e-mail]>; [e-mail]; [e-mail]
> *Subject:* RE: Tunnel-Encap Gaps for SD-WAN described in
> draft-ietf-rtgwg-net2cloud-gap-analysis-02.txt
>
>
>
> John,
>
>
>
> Thank you very much for the feedback.
>
> Comments are inserted below:
>
>
>
> *From:* John E Drake <[e-mail]>
> *<Snip> *
>
>
>
> -------------------------------------------
>
>
>
> -       [Tunnel-Encap] doesn’t have the functionality that would help the
> C-PE to register its WAN Port properties.
>
>
>
> -       A SD-WAN tunnel, e.g. IPsec-based, requires a negotiation between
> the tunnel’s end points for supported encryption algorithms and tunnel
> types before it can be properly established, whereas [Tunnel-Encap]  only
> allow the announcement of one endpoint’s supported encapsulation
> capabilities for specific attached routes and no negotiation between tunnel
> end points is needed.
>
>
>
> *[JD]  What you need to do is implement the model described in  the Secure
> EVPN draft (https://tools.ietf.org/html/draft-sajassi-bess-secure-evpn-01
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint...com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam03.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Ftools.ietf.org-252Fhtml-252Fdraft-2Dsajassi-2Dbess-2Dsecure-2Devpn-2D01-26data-3D02-257C01-257Clinda.dunbar-2540futurewei.com-257C28557a27c1c64de4997708d6f5b30f7f-257C0fee8ff2a3b240189c753a1d5591fedc-257C1-257C1-257C636966546754208641-26sdata-3DqLd2LVx5Lng7QccAIB0weIfpXE3IBOQfq0kiLUJqFMs-253D-26reserved-3D0%26d%3DDwMFAg%26c%3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI%26r%3DCRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE%26m%3Dv-ZrS-NTEa3rPqhwNaoM5gNU8iL1zGd7DutDZaH0C4w%26s%3DnivOMac2lUDvbaJX-GTBeiLAWMqfyKOsTpqvG3AB27A%26e%3D&data=02%7C01%7Clinda.dunbar%40futurewei..com%7C84c6ed1f7cb342efda1208d6f64a6827%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636967196777678003&sdata=3wnRuxLXyDo9qPVXcIfbGNWZMNC37wef0hd4kBJlEWQ%3D&reserved=0>).
> Viz, the SD-WAN C-PEs are attached to a route reflector and each uses the
> route reflector to advertise its security-related  information the other
> C-PEs.  As we discussed in Prague the tunnel encapsulation attribute is not
> associated with client routes.  Rather it is associated with the loopback
> or interface addresses of the advertising SD-WAN C-PE.  I.e., IPv4/IPv6
> addresses rather than VPN IPv4/IPv6 addresses*
>
>
>
> *[Linda]Yes, using Loopback address would be a good way for tunnel, but
> that is not what Tunnel-Encap specified. The draft Tunnel-Encap is to
> advertise supported Encap capabilities for specified routes.*
>
> *I have another section (4.3) on the gap analysis for SECURE-EVPN,
> specifically, Secure-EVPN does not address the scenario of C-PE having some
> ports facing trusted MPLS VPN and other ports facing the untrusted public
> Internet. The document assumes that a client route is either forwarded all
> encrypted through one tunnel, or not encrypted at all through a different
> tunnel. In SD-WAN, one client route can be forwarded encrypted at one time
> through the untrusted network and be forwarded unencrypted at different
> time through MPLS VPN.*
>
> *If you think the secure-evpn has addressed those scenarios, can you
> please indicate which section? Thank you.*
>
>
>
>
>
> The establishment of a SD-WAN tunnel can fail, e.g., in case the two
> endpoints support different encryption algorithms. That is why a SD-WAN
> tunnel needs to be established and maintained independently from
> advertising client routes attached to the edge node.
>
>
>
> *[JD]  See above *
>
>
>
> -       [Tunnel-Encap] requires all tunnels updates are associated with
> routes. There can be many client routes associated with the SD-WAN IPsec
> tunnel between two C-PEs’ WAN ports; the corresponding destination prefixes
> (as announced by the aforementioned routes) may also be reached through the
> VPN underlay without any encryption.. A more realistic approach to separate
> SD-WAN tunnel management from client routes association with the SD-WAN
> tunnels.
>
>
>
> *[JD]  See above *
>
>
>
> -       When SD-WAN tunnel and clients routes are separate, the SD-WAN
> Tunnel establishment may not have routes associated.
>
> There is a suggestion on using a “Fake Route” for a SD-WAN node to use
> [Tunnel-Encap] to advertise its SD-WAN tunnel end-points properties.
> However, using “Fake Route” can raise some design complexity for large
> SD-WAN networks with many tunnels. For example, for a SD-WAN network with
> hundreds of nodes, with each node having many ports & many endpoints to
> establish SD-WAN tunnels with their corresponding peers, the node would
> need as many “fake addresses”. For large SD-WAN networks (such as those
> comprised of more than 10000 nodes), each node might need 10’s thousands of
> “fake addresses”, which is very difficult to manage and requires lots of
> configuration tasks to get the nodes properly set up.
>
>
>
> *[JD]  There is no need for a ‘Fake Route’.  We advertise a tunnel
> encapsulation attribute with security-related information for a specific
> SD-WAN port on the C-PE as identified by its IPv4/IPv6 interface address.
> If a set of SD-WAN ports have common security-related information a tunnel
> encapsulation attribute can be advertised with a C-PE’s loopback address.*
>
>
>
> *[Linda] this section is for Tunnel-Encap, which doesn’t allow Loopback
> address to be associated with the tunnel. If you think it does, can you
> please indicate which section? Thank you.*
>
>
>
> *Linda*
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=iOdQsUCt3t0401DmUlaGf2LNe6GNFoppcHL9UmnRFs0&s=oVYZHedRWOsvb3oxa8GsufcZaZuDs9SgOtCSaMCwEmM&e=
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>