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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
