Re: [Idr] draft-hujun-idr-bgp-ipsec

["Hu, Jun (Nokia - US/Mountain View)" <[e-mail]>]

Agree on changing " Tunnel Encapsulation Attribute for IPsec" to “IPsec TLV” to make it more clear;
But my draft is more than just src/dst prefix mapping to IPsec tunnel, it is to advertise the IPsec configs, the local/remote-prefix sub-TLV are the traffic selector of an IPsec CHILD SA, the color sub-TLV signal the a set of IPsec configurations (typically you only need a few different sets in a network) like transform alg, SA lifetime, DPD settings, PFS …; and optional public routing instance (where ESP/IKE packet is forwarded in)

and I assume the three BGP updates in your example is similar to what described in section 7 (Recursive Next Hop Resolution) of draft-ietf-idr-tunnel-encaps, and the only difference is the all three updates come from same router in your example?

If above understanding is true, I see following problems:

  *   Without remote prefix sub-TLV, there is no way to use different IPsec tunnel config for different source address prefix
  *   Without local prefix sub-TLV (and remote sub-TLV), there is no way to aggregate traffic into a small number of IPsec CHILD SA, or in other words sharing CHILD SA; because local/remote prefix are essentially the traffic selector of the CHILD SA, you could for example using ANY/ANY as local/remote prefix sub-TLV, which could cause traffic between a given pair of router sharing a single CHILD SA; this will greatly decrease the number of CHILD SA needed
  *   It needs additional updates (lo0)

Maybe it is easier to have a f2f discussion during the IETF meeting

From: Robert Raszuk <[e-mail]>
Sent: Saturday, March 9, 2019 6:06 AM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]>
Cc: idr@ietf. org <[e-mail]>
Subject: Re: draft-hujun-idr-bgp-ipsec

Hi,

I see what the intention was, but the current draft does not reflect it well.

You should change all occurrences of: " Tunnel Encapsulation Attribute for IPsec" or "IPsec tunnel encapsulation attribute"
to "IPsec TLV" as there is no such thing like "IPSec tunnel encapsulation attribute" in [I-D.ietf-idr-tunnel-encaps].

But this proposal really defines mapping to IPSec tunnel (based on source & destination prefix and optionally its context) and not really how the IPSec tunnel would be established or what such encapsulation parameters would be.

Context via a list of RTs and remote address prefixes are already indirectly supported today as color of tunnel would match color of extended communities attached to a dst routes so remote addresses for mapping packets within a specific context would be easily achieved today. IMO use of color reference should be preffered solution instead of re-defining a different way to accomplished the same here verbatim.

Mapping based on src prefix perhaps indeed is missing - but I will leave it to WG in general what is the plan to handle src+dst mapping in [I-D.ietf-idr-tunnel-encaps].

In your specific example to achieve the required mapping the encoding would be following:

BGP UPDATE 1 - NLRI lo0
Tunnel Encapsulation Attribute:
      IPsec TLV-1
              - Remote Endpoint 1 sub-tlv
              - color A sub-tlv
       IPsec TLV-2
              - Remote Endpoint 2 sub-tlv
              - color B sub-tlv

BGP UPDATE 2 - NLRI Prefix A
Encapsulation Extended Community
         Color A

BGP UPDATE 3 - NLRI Prefix B
Encapsulation Extended Community
         Color B

Thx,
R.







Thx,
R.


On Sat, Mar 9, 2019 at 7:49 AM Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>> wrote:
Maybe the text in my draft needs to be more clear, but my draft is referencing  [I-D.ietf-idr-tunnel-encaps] ; Yes, according to section 1.4 of [I-D.ietf-idr-tunnel-encaps], IPsec tunnel is out of its scope, that’s why my draft says it extends [I-D.ietf-idr-tunnel-encaps] to support IPsec tunnel;

So when I say “the BGP update of NLRI prefix C need to include a Tunnel Encap attr, which include two IPsec TLVs…”, it means the BGP update include a Tunnel Encap attr as specified in section-2 of [I-D.ietf-idr-tunnel-encaps], and this Tunnel Encap attr include two TLVs:

  *   TLV-1: Tunnel Type is 4 (I propose to reuse 4 for IPsec tunnel), TLV-1 contains following sub-TLV:

     *   Remote Endpoint (as specified in section 3.1 of [I-D.ietf-idr-tunnel-encaps]) : local IPsec tunnel endpoint address of advertising router
     *   remote-prefix : pA
     *   color (as specified in 3.4.2 of [I-D.ietf-idr-tunnel-encaps], but has new semantics for IPsec): A

  *   TLV-2: Tunnel Type is 4 , TLV-2 contains following sub-TLV:

     *   Remote Endpoint: local IPsec tunnel endpoint address of advertising router
     *   remote-prefix: pB
     *   color: B

hope this make things clearer

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Friday, March 8, 2019 3:19 PM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>
Cc: idr@ietf. org <[e-mail]<mailto:[e-mail]>>
Subject: Re: draft-hujun-idr-bgp-ipsec

Hi,

I think that the references are a bit wrong. And the confusion may be not even your own fault,
but IETF process related.

I was looking for type 4 tunnel type in your normative reference but there is none.


[I-D.ietf-idr-tunnel-encaps]

              Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel

              Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-11<https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-11>

              (work in progress), February 2019.



The reference your text may be referring to is perhaps RFC5566 instead

since this is where type 4 for IPSec in Tunnel mode was defined. Different document.



Unfortunately 5566 relied on 5512 which is obsoleted now. And we never

concluded how any references to 5566 should be now handled.



1.4<https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-11#section-1.4>.  Impact on RFC 5566<https://tools.ietf.org/html/rfc5566>





   [RFC5566] uses the mechanisms defined in [RFC5512<https://tools.ietf.org/html/rfc5512>].  While this

   document obsoletes [RFC5512<https://tools.ietf.org/html/rfc5512>], it does not address the issue of how to

   use the mechanisms of [RFC5566<https://tools.ietf.org/html/rfc5566>] without also using the Encapsulation

   SAFI.  Those issues are considered to be outside the scope of this

   document.



And [I-D.ietf-idr-tunnel-encaps] does not define anything for IPSec.



So bottom line based on the current definition of Tunnel Encapsulation

Attribute I am not sure where and how you want to provide the defined

herein extensions.



Therefor it is now hard to comment on encoding specifics of provided examples

for two IPSec tunnel signalling options till normative references are sorted out.



Thx,

RR.



On Fri, Mar 8, 2019 at 11:48 PM Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>> wrote:
I agree that making remote prefix sub-TLV optional and absence of it means ANY is a better idea, will update the draft and example in it;

To address use case in your email, the BGP update of NLRI prefix C need to include a Tunnel Encap attr, which include two IPsec TLVs:

  *   IPsec TLV-1: include remote-prefix sub-TLV pA and color sub TLV A
  *   IPsec TLV-2: include remote-prefix sub-TLV pB and color sub TLV B



From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Friday, March 8, 2019 2:26 PM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>
Cc: idr@ietf. org <[e-mail]<mailto:[e-mail]>>
Subject: Re: draft-hujun-idr-bgp-ipsec


Ok that was not very clear from the draft. While your explanation is good - there may be folks who will try to include all remote prefixes as this sub-TLV is mandatory. I guess if instead of all zero's you make it also optional the room for bad encoding becomes smaller.

But let's assume that you have two different IPSec encapsulation requirements A & B for the same local prefix C and two different remote prefixes pA & pB.

How would you encode it in the single update msg ?

Thx,
R.

On Fri, Mar 8, 2019 at 10:31 PM Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>> wrote:
Thanks for reviewing the draft;
In your example (500 routers), R2 doesn’t necessary need to advertise 500 remote prefixes because if R2 doesn’t have 500 different types IPsec encapsulation requirements for the NLRI, what it could do it just include a single all-zero remote prefix, means traffic from any source destined to this NLRI should use this particular IPsec tunnel encapsulation config;  and I would expect using all-zero remote prefix would be the common use case;

From: Robert Raszuk <[e-mail]<mailto:[e-mail]>>
Sent: Friday, March 8, 2019 12:49 PM
To: Hu, Jun (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>
Cc: idr@ietf. org <[e-mail]<mailto:[e-mail]>>
Subject: draft-hujun-idr-bgp-ipsec

Hi,

I have read your proposal and have one question.

The proposed encoding of additional sub-TLVs define local and remote prefixes as traffic selectors. Looks great in your example of two end points only. But introduction talks about scale so let's consider scale factor.

Assume you have 500 routers in the domain.

When you advertise subnet B or C from R2 now you need to include in mandatory Remote prefix sub-TLV 500 ingress prefixes as for each subnet advertised you can only send it once in BGP. Then each ingress PE receiving this huge list would need now to store all 500 ingress ACLs (mappings to IPSec tunnels) where in fact perhaps realistically only one or two ingress traffic subnets may ever be traversing via given edge router.

And 500 is just following your example where ingress prefixes are directly attached to ingress router (subnet A to R1). There can be valid mapping cases where such sources are not directly attached.

This really does not look at all efficient and is prone to generate a lot of unnecessary state directly proportional to network size or expected incoming src prefix number.

If you really would like to use p2mp protocol for this configuration push I would recommend to leave the current Tunnel Encapsulation Attribute unchanged and simply propose to define a new SAFI with proper NLRI syntax that it is precisely efficient to the very application you describe.

Effectively what you are proposing is to carry in BGP src+dst based mapping to IPSec tunnel deeply embedding this into sub-TLVs of tunnel encapsulation attribute.

In principle I agree that we do see more and more use cases for src+dst based IP lookups both for native forwarding and with some form of encapsulation but the proposed nested and not efficient encoding IMO requires to be modified to work well in the assumed large scale.

Thx a lot,
R.