Subject: [lisp] draft-ietf-lisp-15 review

From: Ari Keranen <[email-masked]>
Date: Thu, 20 Oct 2011 11:01:23 +0300

Hi,

I read through the draft-ietf-lisp-15 and here's some comments (note 
that this is the first time I read the whole draft and I haven't 
followed closely the discussions on the list, so some of these issues 
may already have been discussed):

The security features seem fairly weak. I guess that's OK for an 
experimental spec, but saying that "[...] nonce, coupled with the ITR 
accepting only solicited Map-Replies goes a long way toward providing 
decent authentication" (in the security considerations section) seems a 
bit misleading, especially considering on-path attackers. I think the 
security considerations section should be more clear on that.

The basic overview section says that "EIDs are not expected to be usable 
for global end-to-end communication". From this I'd assume that with 
IPv4 RFC1918 addresses are commonly used as EIDs. However, sometimes 
packets seem to be sent directly to EIDs outside of LAN, e.g., section 
6.1.3 says "For the initial case, the destination IP address used for 
the Map-Request is the destination-EID from the packet which had a 
mapping cache lookup failure". How does this work with RFC1918 addresses?

More specific comments and nits:

2.  Introduction

    interface is intended to make the mapping database modular so that
    different approaches can be tried without the need to modify
    installed xTRs.

First instance of "xTR"; could use something generic like "LISP tunnel 
router" in the intro text instead.

3.  Definition of Terms

       That is, a site which receives an explicitly
       allocated EID-prefix may not use that EID-prefix as a globally
       prefix.

What is "globally prefix"?

    Data Probe:   A data-probe is a LISP-encapsulated data packet where
       the inner header destination address equals the outer header
       destination address used to trigger a Map-Reply by a decapsulating

It would help to have "Map-Reply" and request defined before "Data Probe".

4.1.  Packet Flow Sequence

    5.  The ETR looks at the destination EID of the Map-Request and
        matches it against the prefixes in the ETR's configured EID-to-
        RLOC mapping database. [...]  If there is no match,
        the Map-Request is dropped.

I found it surprising that the Map-Request is (silently) dropped if 
there's no match. Wouldn't the request be then just re-transmitted to 
cope with packet loss? And how many times (I missed the discussion on 
re-transmissions too)?

5.4.2.  A Stateful Solution to MTU Handling

There's no discussion/recommendations on what kind of time-out values 
should be used for the MTU cache entries.

6.1.  LISP IPv4 and IPv6 Control Plane Packet Formats

    The UDP Checksum is computed and set to non-zero for Map-Request,
    Map-Reply, Map-Register and ECM control messages.

First (and only) instance of ECM; expand.

6.1.2.  Map-Request Message Format

    A: This is an authoritative bit, which is set to 0 for UDP-based Map-
       Requests sent by an ITR.

Could move the description of A-bit from 6.1.4 already here.

       The nonce
       SHOULD be generated by a properly seeded pseudo-random (or strong
       random) source.

This being one of the main security features, a "SHOULD" sounds pretty 
weak; I'd make it a MUST.

6.1.4.  Map-Reply Message Format

       If all weights for a locator-set are equal,
       receiver of the Map-Reply will decide how to load-split traffic.

Should this be "if all weights are 0" as discussed in section 6.2., 4th 
bullet?

6.1.5.  EID-to-RLOC UDP Map-Reply Message

    the local IP addresses chosen to allow uRPF checks to succeed in the

First (and only) instance of uRPF; expand (and add refence?)

6.2.  Routing Locator Selection

    When
    the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the
    RLOC.

Should that rather be "MUST NOT send LISP encapsulated traffic toward 
RLOC" or something?

Cheers,
Ari

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 20 Oct 2011 11:02:50 -0400

Ari, on what basis did you come to the conclusion below.
The goal (putting aside transition) is not that EIDs will come from 1918 
space, but that we will be able to remove the EID blocks (and their 
dis-aggregations) from the global routing table.

The use of the EID as the destination is within the ALT (or other 
mapping systems).  EIDs must be unique within a mapping system.

Yours,
Joel

---

From: Ari Keranen <[email-masked]>
Date: Thu, 20 Oct 2011 19:05:00 +0300

Hi Joel,

I got that impression from the text I cited below and from the examples 
in the draft using the 10/8 space. If the "common case" (at least 
eventually) is using the globally routed addresses blocks, perhaps that 
could be explicitly stated, e.g., somewhere in the beginning of section 4?

And apparently at least Map-Requests can be sent without ALT using the 
"underlying routing system topology" (section 4.1.) and EID as 
destination address (sec 6.1.3). Doesn't this break if the EID blocks 
are removed from the global routing table?

Cheers,
Ari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 23 Oct 2011 15:47:04 +0300

By the way, it is interesting that Ari thought the EIDs would come out of 10/8 space. That is obviously wrong, but maybe this misunderstanding gives us a datapoint on the issue that I raised earlier about using the 10/8 addresses in examples.

Jari

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 23 Oct 2011 12:30:17 -0700

> By the way, it is interesting that Ari thought the EIDs would come out of 10/8 space. That is obviously wrong, but maybe this misunderstanding gives us a datapoint on the issue that I raised earlie…

Ah, but they could. That is the point. Since they are not injected in the core, an EID-prefix in 10/8 space can be made unique to both the mapping database and the data-plane core by coupling it with an instance-ID. And the instance-ID need only be unique *per mapping database system*.

Dino

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

---

From: Jari Arkko <[email-masked]>
Date: Sun, 23 Oct 2011 22:48:13 +0300

Yes, but setting up the entire system so that this works would be challenging (how names resolve to addresses, how applications know about this, etc). But it probably doesn't matter, it is of course true that it could be done. My point was that this is probably not the usual configuration, and at least one reader got confused by the use of private addresses in the examples. I'm not holding this as a blocking comment in my review, but if it were my spec I would probably change the addresses to something else.

Jari

---

From: Alia Atlas <[email-masked]>
Date: Sun, 23 Oct 2011 16:17:46 -0400

As I recall, all of the details to pass Instance-ID weren't there for
the ALT mapping database.  I'd have to review my earlier comments, but
I also found this confusing and considered the idea of the
Instance-IDs as one of those concepts that wasn't sufficiently
developed in the spec.

Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 23 Oct 2011 16:53:59 -0400

The problem I have with that view is that although it is accurate, it is 
also bascially not explained.
For charter reasons, we left out any explanation of the private spaces, 
other than putting in the hook for instance-ID.

So, yes, as long as all of the users of a given mapping system and given 
instance ID use 10/ space in a consistent fashion for allocating IDs, it 
will work.  But I don't see how a reader could understand that from the 
document.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Oct 2011 00:48:49 -0700

Instance-IDs are there (in the LCAF draft) to support LISP-VPNs. There is nothing in the main specifications because VPNs are out of scope for the LISP WG.

Dino

On Oct 23, 2011, at 1:53 PM, Joel M. Halpern wrote:

> The problem I have with that view is that although it is accurate, it is also bascially not explained.
> For charter reasons, we left out any explanation of the private spaces, other than putting in the hook for instance-ID.
> 
> So, yes, as long as all of the users of a given mapping system and given instance ID use 10/ space in a consistent fashion for allocating IDs, it will work.  But I don't see how a reader could understand that from the document.
> 
> Yours,
> Joel
>