Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites
draft-ietf-lisp-interworking-06

[Ballot comment]
0. Thanks for addressing my issue regarding private addresses in section 7.2

1. Thanks for adding Figure 1.  Section 7.2 (discussing private addresses)
might benefit from an extension to Figure 1 that demonstrates where the
NAT function fits.

2. Cleared.

3. Cleared.

4. Cleared.

[Ballot discuss]
I'm hoping this Discuss point will be easy to resolve.

1. In section 7.2, are these hosts using RFC 1918 addresses as EIDs?
I thought from the discussion of the base LISP document that EIDs have
to be globally unique.

[Ballot comment]
1. I agree with Adrian's comment that the document would be much more
easily understood with a diagram of the various architectural elements
and alternatives.  For example, I had a hard time visualizing the
placement of Proxy-ITRs and how that placement would affect the
advertisement of routes to EIDs.

2. Section 7.3, although interesting, seems out of scope for this
document.

3. In section 8, "there are three mechanisms for interworking LISP
with non-LISP Sites" seems to ignore the use of routable EIDs as
described in section 4.

4. Section 1 claims that:

  [...] EID
  prefixes are normally not advertised into the Internet's Default Free
  Zone (DFZ)

But section 4 is all about routable EIDs, which seems to contradict
the claim in section 1.

[Ballot comment]
- Its not clear to me that the mapping system can reliably know
that all non-LISP IP addresses are in fact not EIDs. But I'm
willing to suspend disbelief for the experiment:-)

[Ballot comment]
Default Free Zone (DFZ) should have a reference, if only a forward ref to section 2 when you first use it in section 1

====

Asymmetry is a problem with certain types of application, NTP for example. It would be useful if there was some discussion on the relative degree of asymmetry imposed by these LISP solutions vs the degree of asymmetry in the existing Internet, and a note made about the impact of asymmetry on applications

[Ballot discuss]
I only have a minor Discussion point (do I hear the authors sighing?)

Section 4.2 says

  Non-LISP sites today use BGP to, among other things, enable ingress
  traffic engineering.  Relaxing this requirement is another primary
  design goal of LISP.

I went back to look for the description of this design goal in the LISP
spec and I couldn't find it. Might be my search was a bit random. Might
be the design goal wasn't stated in the base spec and so shouldn't be
claimed here.

[Ballot comment]
Thank you for the paragraph at the end of the Introduction.

---


This document would be made significantly more useful by the addition
of a figure showing the architectural components.

---

Please s/draft/document/ throughout.

---

Section 2

  For traffic not to be
  dropped, either some mechanism to make this destination EID routable
  must be in place.

Typo "either", or missing "or".

---

Section 5.2

Are there any consequences of the assymetry of PITR use that we should
investigate? Yes, I know that the Internet is not always symmetric,
but in general it often is.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Interworking LISP with IPv4 and IPv6) to Experimental RFC


The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'Interworking LISP with IPv4 and IPv6'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes techniques for allowing sites running the
  Locator/ID Separation Protocol (LISP) to interoperate with Internet
  sites (which may be using either IPv4, IPv6, or both) but which are
  not running LISP.  A fundamental property of LISP speaking sites is
  that they use Endpoint Identifiers (EIDs), rather than traditional IP
  addresses, in the source and destination fields of all traffic they
  emit or receive.  While EIDs are syntactically identical to IPv4 or
  IPv6 addresses, normally routes to them are not carried in the global
  routing system so an interoperability mechanism is needed for non-
  LISP-speaking sites to exchange traffic with LISP-speaking sites.
  This document introduces three such mechanisms.  The first uses a new
  network element, the LISP Proxy Ingress Tunnel Routers (PITR)
  (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR)
  for non-LISP-speaking hosts.  Second the document adds Network
  Address Translation (NAT) functionality to LISP Ingress and LISP
  Egress Tunnel Routers (xTRs) to substitute routable IP addresses for
  non-routable EIDs.  Finally, this document introduces a Proxy Egress
  Tunnel Router (PETR) to handle cases where a LISP ITR cannot send
  packets to non-LISP sites without encapsulation.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-lisp-interworking/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-lisp-interworking/


No IPR declarations have been submitted directly on this I-D.

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. 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. 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. 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. 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.)

(1.a) Terry Manderson is the Shepherd and has reviewed this version
and believes it is ready to be forwarded to the IESG.

(1.b) The document has had adequate review. The shepherd has no concerns
regarding the reviews which have been performed.

(1.c) The document shepherd does not have concerns that the document
requires a broader review.

(1.d) The document shepherd has no specific concerns, No IPR disclosures
have been raised.

(1.e) The WG consensus reflects active agreement among about about 10
participants, with the bulk of the WG being silent.

(1.f) No threats of appeal or discontent on this document have manifested.

(1.g) IDNITs responds with:



== There are 16 instances of lines with non-RFC5735-compliant IPv4
addresses in the document. If these are example addresses, they should
be changed.

== There are 3 instances of lines with private range IPv4 addresses in the
document. If these are generic example addresses, they should be
changed to use any of the ranges defined in RFC 5735 (or successor):
192.0.2.x, 198.51.100.x or 203.0.113.x.


The authors responded with the need to call on a broader and deeper
set of example prefixes to add meaning to the document. Documentation
prefixes alone could not provide this so RFC1918 based addresses were used.


(1.h) References have been split. No downward normative references exist.
The WIP documents are listed as normative references. All three
documents will be submitted to the IESG at the same time as this
document.

(1.i) The document makes no request of the IANA

(1.j) Formal language has been verified.

(1.k)

Technical Summary

This document describes techniques for allowing sites running the
Locator/ID Separation Protocol (LISP) to interoperate with Internet
sites (which may be using either IPv4, IPv6, or both) but which are
not running LISP. A fundamental property of LISP speaking sites is
that they use Endpoint Identifiers (EIDs), rather than traditional IP
addresses, in the source and destination fields of all traffic they
emit or receive. While EIDs are syntactically identical to IPv4 or
IPv6 addresses, normally routes to them are not carried in the global
routing system so an interoperability mechanism is needed for non-
LISP-speaking sites to exchange traffic with LISP-speaking sites.
This document introduces three such mechanisms. The first uses a new
network element, the LISP Proxy Ingress Tunnel Routers (PITR)
(Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR)
for non-LISP-speaking hosts. Second the document adds Network
Address Translation (NAT) functionality to LISP Ingress and LISP
Egress Tunnel Routers (xTRs) to substitute routable IP addresses for
non-routable EIDs. Finally, this document introduces a Proxy Egress
Tunnel Router (PETR) to handle cases where a LISP ITR cannot send
packets to non-LISP sites without encapsulation.


Working Group Summary

The work group process for this document was uneventful.

Document Quality

This document is a descriptive tome for techniques in LISP
interoperation. It has had significant review as with all other LISP
documents.