Subject: [lisp] AD review of draft-ietf-lisp-interworking

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Jan 2012 11:27:28 +0200

I have reviewed this document.

In general, it is well written and almost ready to go forward. There are a couple of areas that need further text, however. The main issue is a clear description of the to-experiment and problematic areas of LISP interworking. (Making those is also needed in order to get the document approved, based on experience of taking the other Lisp documents to the IESG.) Another issue is that I think the security considerations text needs work.

In moder detail:

Technical issue: As with the other documents from the group, Section 1 should include a high-level explanation of what issues are uncertain, potentially problematic, or worth experimenting on. For instance, I presume you should say something about the effects of having to NAT traffic, finding deployment motivations to set up proxy ITRs, possible inclusion of too much non-aggregated EID space in the DFZ, effects of the asymmetric PITR routing, and so on.

Please suggest text.

> An ITR can also know explicitly that the
> destination is non-LISP if the destination IP address matches a
> Negative Map Reply found in its Map Cache.

Technical issue: This is normally the case, but the text seems to avoid going into the details that I think are relevant in this case. The base spec says

    There are two primary applications for
    Negative Map-Replies.  The first is for a Map-Resolver to instruct an
    ITR or PITR when a destination is for a LISP site versus a non-LISP
    site.  And the other is to source quench Map-Requests which are sent
    for non-allocated EIDs.

and

     The actions defined are used by an ITR or PITR when a
     destination EID matches a negative mapping cache entry.
     Unassigned values should cause a map-cache entry to be created
     and, when packets match this negative cache entry, they will be
     dropped.  The current assigned values are:

       (0) No-Action:  The map-cache is kept alive and no packet
          encapsulation occurs.

       (1) Natively-Forward:  The packet is not encapsulated or dropped
          but natively forwarded.

       (2) Send-Map-Request:  The packet invokes sending a Map-Request.

       (3) Drop:  A packet that matches this map-cache entry is dropped.
          An ICMP Unreachable message SHOULD be sent.

That is, first of all there are other situations for which negative map cache entries are used (but it is probably fine to route to the Internet in those cases). Secondly, there are some controls on whether native forwarding is the appropriate action.

Can you add a note about these and/or reformulate the text a bit?

>     3.  In either of the two exceptions mentioned above there could be
>

Editorial issue: I was unsure what "the two exceptions mentioned above" refer to. Also, your list starts with "This can be achieved by using one of two mechanisms:", so it is odd to find three items in the list. I would suggest making this paragraph a regular paragraph and not a numbered item, and starting it with "In either of the two mechanisms listed above there could be ...".

> 5.  Proxy Ingress Tunnel Routers

Editorial issue: It may be too obvious perhaps, but I think this section should state up front that highly aggregated EID space advertisement implies an entity that routes on the behalf of many LISP sites.

>     240.0.0.0/24.  For the purposes of this example, this prefix and no
>

Editorial issue: Is there a reason why we are using 240 addresses as examples? I'd prefer using normal example addresses or 10/8 addresses if you need shorter prefixes...

> For the purposes of this example, this prefix and no
> covering aggregate is present in the global routing system.

Editorial issue: Shouldn't this be "... neither this prefix or any covering aggregate are present ...". The way that you have written it now had me confused for a moment, thinking that this prefix is present but no covering prefix is present. I don't think that is what you mean.

>
>     6 <http://tools.ietf.org/html/draft-ietf-lisp-interworking-02#section-6>. LISP-NAT
>
>
>

Technical issue: Section 6 should probably point to some BEHAVE WG RFCs on how the NAT operation should technically work.

> An example of this translation follows.  For this example, a site has
> been assigned a LISP-NR EID of 220.1.1.0/24.  In order to utilize
> LISP-NAT, the site has also been provided the PA EID of
> 128.200.1.0/24, and uses the first address (128.200.1.1) as the
> site's RLOC.  The rest of this PA space (128.200.1.2 to
> 128.200.1.254) is used as a translation pool for this site's hosts
> who need to send packets to non-LISP hosts.
>

Editorial issue: Please use the officially allocated example addresses.

>
>       6.4 <http://tools.ietf.org/html/draft-ietf-lisp-interworking-02#section-6.4>. LISP-NAT and multiple EIDs
>
>
>
>     When a site has two addresses that a host might use for global
>     reachability, care must be chosen on which EID is found in DNS.  For
>     example, whether applications such as DNS use the LISP-R EID or the
>     LISP-NR EID.  This problem exists for NAT in general, but the
>     specific issue described above is unique to LISP.  Using PITRs can
>     mitigate this problem, since the LISP-NR EID can be reached in all
>     cases.

Technical issue: but if you had a PITR, you would not need LISP-NAT, or am I missing something?

>
>       6.5 <http://tools.ietf.org/html/draft-ietf-lisp-interworking-02#section-6.5>. When LISP-NAT and PITRs used by the same LISP Site
>
>
>
>     With LISP-NAT, there are two EIDs possible for a given host, the
>     LISP-R EID and the LISP-NR EID.  When a site has two addresses that a
>     host might use for global reachability, name-to-address directories
>     may need to be modified.
>
>     This problem, global vs. local addressability, exists for NAT in
>     general, but the specific issue described above is unique to
>     location/identity separation schemes.  Some of these have suggested
>     running a separate DNS instance for new types of EIDs.  This solves
>     the problem but introduces complexity for the site.  Alternatively,
>     using PITRs can mitigate this problem, because the LISP-NR EID can be
>     reached in all cases.

Editorial issue: what's the difference between Sections 6.4 and 6.5? It seems that they both talk about the problem of two addresses in a name mapping system.

Technical issue: I don't think "introduces complexity for the site" begins to explain the type of problems caused by having to separate naming systems from each other. Please expand or otherwise highlight that this approach is problematic.

>
>     8 <http://tools.ietf.org/html/draft-ietf-lisp-interworking-02#section-8>. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs)
>
>
>
>   In summary, there are three mechanisms for interworking LISP with
>   non-LISP Sites (for both IPv4 and IPv6).  In the LISP-NAT option the
>   LISP site can manage and control the interworking on its own.  In the
>   PITR case, the site is not required to manage the advertisement of
>   it's EID prefix into the DFZ, with the cost of potentially adding
>   stretch to the connections of non-LISP sites sending packets to the
>   LISP site.  The third option is Proxy-ETRs, which are optionally used
>   by sites relying on PITRs case to mitigate two caveats for LISP sites
>   sending packets to non-LISP sites.  This means Proxy-ETRs are not
>   usually expected to be deployed by themselves, rather they will be
>   used to assist LISP-NR sites which are already using PITRs.
>

Technical issue: This paragraph and Setion 8 in general would greatly from a discussion of the tradeoffs involved in these three mechanisms. Just one downside, stretch, is mentioned above. But I think there are others... impacts to naming systems, asymmetric traffic, etc. Please expand.

> 9. Security Considerations

Technical issue: This section seems a bit thin. I'd love to see a discussion of the following additional issues:

Implications to firewalls? Are there any? What about asymmetric routing?

Are there Denial-of-service attacks on PITRs and PETRs?

Are there DNSSEC implications on the naming system implications?

>     Like any router or LISP ITR, PITRs will have the opportunity to
>     inspect traffic at the time that they encapsulate.  The location of
>     these devices in the network can have implications for discarding
>     malicious traffic on behalf of ETRs which request this behavior (via
>     the drop action bit in Map-Reply packets for an EID or EID prefix).
>

You should also talk about these devices being trusted to route your traffic to begin with, and how both non-Lisp and Lisp networks should be careful in not peering with untrustworthy networks. This is very similar to, say, peering with someone who says they can reach everything in the Internet but in reality their quality or security leaves something to be desired.

(Of course, all additions to the security considerations text could be pointers elsewhere, if the issues have already been noted in other documents.)

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Jan 2012 17:31:51 +0200

Was there a response on this,  and a new document version, or did I miss something? I'd like to take this document forward but we need those changes first.

I realize that you have many documents still in the IESG discussion, but part of the criticism that we've gotten in IESG review is that they wanted to see the whole system, not just pieces. The interworking document is an important part of the system, so it would be good to get it up for the final review as well.

Jari

---

From: Darrel Lewis <[email-masked]>
Date: Mon, 23 Jan 2012 13:06:17 -0800

Hi Jari, 

Sorry I was sick last week and this has been on my queue.

I am responding to your text now.  Thanks!

-Darrel
On Jan 19, 2012, at 7:31 AM, Jari Arkko wrote:

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