I have reviewed this draft. This is another well written and easy to understand
document. Thank you for that.
I only found minor editorial issues, one security aspect that you should
document, and couple of small technical comments. I have sent the document
forward to IETF Last Call anyway. Please revise the draft as soon as you can
(even during Last Call). Ask me if something was unclear or I missed something.
Technical:
The feature
introduced by Map-Version numbers is the possibility of blocking
traffic from ITRs not using the latest mapping. Indeed, after a
certain number of retries, if the Destination Map-Version number
in the packets is not updated, the ETR MAY silently drop packets
with a stale Map-Version number. This because either the ITR is
refusing to use the mapping for which the ETR is authoritative or
(worse) it might be some form of attack.
I have two small comments about this. First, since an attack could spoof the
source address, it is important to restrict the blocking to the offending
traffic, not all traffic from a given ITR address. And this is your intention,
as can be seen from the second sentence. Could you make the following change to
make this even clearer in the first sentence as well: s/blocking traffic from
ITRs not using the latest mapping/blocking traffic not using the latest
mapping/.
Second, I'm not sure I understand the different failure cases here. What if
there's a network issue that causes unidirectional connectivity? We'd receive
lisp encapsulated packets, but our attempts to send commands to update the
mapping would be unsuccessful, as the traffic does not get through. In light of
this, is the right action to start dropping packets on our side? Or maybe there
is something else in Lisp that prevents us from getting into this situation.
Please explain. And if you are not sure what the implications are, please
indicate that in the text.
3. The packet arrives with a Source Map-Version number smaller
(i.e., older) than the one stored in the local EID-to-RLOC Cache.
Such a case is not valid w.r.t. the specifications. Indeed, if
the mapping is already present in the EID-to-RLOC Cache, this
means that an explicit Map-Request has been sent and a Map-Reply
has been received from an authoritative source. Assuming that
the mapping system is not corrupted anyhow, the Map-Version in
the EID-to-RLOC Cache is the correct one and the packet MAY be
silently dropped.
I worry that there's a dependency on something which cannot be fully secured in
the real-world, and if someone starts to drop packets due to an inconsistency
there is no easy way to recover. I would suggest adding something to the
security considerations section about reliance on the security of the mapping
system and aggressive drop policies leading to the possibility of difficult
recovery from a temporary mapping system issue.
Once no more traffic is received by the RLOC, because all sites have
updated the mapping, it can be shut down safely.
Technically, there might be a mapping on some other site that has not had a
reason to send a packet yet. But if it then sends a packet, it might use a
locally cached copy of the mapping and the packet goes to the wrong place.
Perhaps you should clarify this. E.g. " ... received by the RLOC, it can be shut
down in relatively safety, because at least all sites actively using the mapping have
updated it."
Editorial:
This document describes the LISP Map-Versioning mechanism, which
provides in-packet information about EID-to-RLOC mappings used to
encapsulate LISP data packets. The proposed approach is based on
associating a version number to EID-to-RLOC mappings and transport
such a version number in the LISP specific header of LISP-
encapsulated packets. LISP Map-Versioning is particularly useful to
inform communicating xTRs about modifications of the mappings used to
encapsulate packets. The mechanism is transparent to legacy
implementations, since in the LISP-specific header and in the Map
Records, bits used for Map-Versioning can be safely ignored by xTRs
that do not support the mechanism.
You should expand EID, RLOC, and xTR, as this is the abstract (it can be read
by someone without seeing the rest of the document).
When Map-Versioning is used, LISP-encapsulated data packets contain
the version number of the two mappings used to select the RLOCs in
the outer header (i.e., both source and destination). These version
numbers are encoded in the 24 low-order bits of the first longword of
the LISP header and indicated by a specific bit in the flags (first 8
high-order bits of the first longword of the LISP header). Note that
not all packets need to carry version numbers.
I'd prefer seeing a reference to draft-ietf-lisp and section number that
defines the Lisp header.
The Map-Request will either trigger a Map-Request back
using the SMR bit or it will piggyback the newer mapping. These
are not new mechanisms; how to SMR or piggyback mappings in Map-
Request messages is already described in [I-D.ietf-lisp],
Expand SMR.
A Proxy-ETR does not have any mapping, since it just decapsulate
packets arriving from LISP site.
s/decapsulate/decapsulates/
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
