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

[Robert Raszuk <[e-mail]>]

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]> 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]>
> *Sent:* Friday, March 8, 2019 3:19 PM
> *To:* Hu, Jun (Nokia - US/Mountain View) <[e-mail]>
> *Cc:* idr@ietf. org <[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]> 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]>
> *Sent:* Friday, March 8, 2019 2:26 PM
> *To:* Hu, Jun (Nokia - US/Mountain View) <[e-mail]>
> *Cc:* idr@ietf. org <[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]> 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]>
> *Sent:* Friday, March 8, 2019 12:49 PM
> *To:* Hu, Jun (Nokia - US/Mountain View) <[e-mail]>
> *Cc:* idr@ietf. org <[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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>