Dear authors/WG:
While I appreciate the small number of changes from rfc6834 and the
original intent (from 2018) of processing this document quickly, but
it requires a non-trivial amount of work. It is now going for
Proposed Standard, so we need to be more rigorous.
I put detailed comments inline (below). There are two main themes
that I want to highlight here:
(1) Duplication and overlap
Several parts of this document describe the same or related behaviors.
This issue has resulted in duplicate descriptions and specifications, not
all of them saying the same thing. :-( The problem extends beyond this
document into both rfc6830bis and rfc6833bis. I pointed and cross-
referenced the sections as best as I could below.
In general, please specify the behavior only once. Doing so in multiple
places can be confusing and, as in this case, result in the specifications
not being in sync.
Note that to address this point we may need to update rfc6830bis and
rfc6833bis. I would prefer to see as much of the specification related to
Map-Versioning as possible (all?) in this document. Removing pieces and
referencing this document shouldn't require removing them from the RFC
Editor's queue -- and they both Normatively depend on this document anyway.
One specific action is to remove the text from §13.2/rfc6830bis. Some of
it is already covered in this document -- the remaining pieces, which I
believe are only the last couple of paragraphs, can find a better home.
(2) Document Structure
As I started reading this document, I found myself going back to rfc6830bis
to look for packet formats -- and I wasn't even past the Introduction! I
then realized that some of the information was in this document but an
unexpected order. Some actionable comments:
(1) Simplify the Introduction; there's too much detail. For example, it
mentions the location of the Map-Version in excruciating detail ("the 24
low-order bits of the first longword of the LISP header"), but the
description is wrong (see more inline). There are explanations about the
topics later on but no forward references. Instead, paint a high-level
picture and tell the reader where to find the details.
(2) Beyond the Introduction, the document is ordered in a cumbersome way:
The location and format of the Map-Version are presented in §6, but both
§4/§5 describe how the versions are handled. It would be much better for
the reader if §6 were moved forward. This is my suggested ordering:
6. LISP Header and Map-Version Numbers
7. Map Record and Map-Version (this could be a subsection)
4. EID-to-RLOC Map-Version Number
5. Dealing with Map-Version Numbers
Also, I suggest moving §8 to an Appendix.
As we have a constrained timeline for this document, I would like to
start the IETF Last-Call by the end of this month. I have a lot of
comments, but I don't think they will be hard to address.
Please reply inline to this message to expedite my review of any
updates. Also, if you think talking would clear things up faster,
feel free to find time on my calendar:
https://doodle.com/mm/alvaroretana/book-a-time
Padma: As Shepherd, I'll need you to please update the writeup when
the final version is ready.
Thanks!!
Alvaro.
[Line numbers from idnits.]
...
13 Abstract
15 This document describes the LISP (Locator/ID Separation Protocol)
16 Map-Versioning mechanism, which provides in-packet information about
17 Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to
18 encapsulate LISP data packets. The proposed approach is based on
19 associating a version number to EID-to-RLOC mappings and the
20 transport of such a version number in the LISP-specific header of
21 LISP-encapsulated packets. LISP Map-Versioning is particularly
22 useful to inform communicating Ingress Tunnel Routers (ITRs) and
23 Egress Tunnel Routers (ETRs) about modifications of the mappings used
24 to encapsulate packets. The mechanism is optional and transparent to
25 implementations not supporting this feature, since in the LISP-
26 specific header and in the Map Records, bits used for Map-Versioning
27 can be safely ignored by ITRs and ETRs that do not support or do not
28 want to use the mechanism.
[minor] s/proposed//g
This mechanism is now on the standards track, so it is not "proposed"
any more. :-)
...
93 1. Introduction
[] As I mentioned above, please simplify this section. I left
comments below, but I think that most of the text can be changed for a
high-level description.
...
113 When Map-Versioning is used, LISP-encapsulated data packets contain
114 the version number of the two mappings used to select the RLOCs in
115 the outer header (i.e., both source and destination RLOCs). These
116 version numbers are encoded in the 24 low-order bits of the first
117 longword of the LISP header and indicated by a specific bit in the
118 flags (first 8 high-order bits of the first longword of the LISP
119 header). Note that not all packets need to carry version numbers.
[major] "version numbers are encoded in the 24 low-order bits of the
first longword of the LISP header"
Wow! That's not an easy reference to follow!
I went to find the "LISP Header" and found this definition in rfc6830bis:
LISP Header: LISP header is a term used in this document to refer
to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
specific 8-octet header that follow the UDP header and that an ITR
prepends or an ETR strips.
If the LISP Header includes the "outer IPv4 or IPv6 header, a UDP
header, and a LISP-specific 8-octet header" then the "24 low-order
bits of the first longword" maps to something different. :-(
Instead, it would be easier for everyone to simple show the header
with the V-bit set (from rfc6830bis):
0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[major] "indicated by a specific bit in the flags (first 8 high-order
bits of the first longword of the LISP header)."
Please replace that with a specific mention to the V-bit.
121 When an ITR (Ingress Tunnel Router) encapsulates a data packet, with
122 a LISP header containing the Map-Version numbers, it puts in the
123 LISP-specific header two version numbers:
125 1. The version number assigned to the mapping used to select the
126 source RLOC (contained in the EID-to-RLOC Database).
128 2. The version number assigned to the mapping used to select the
129 destination RLOC (contained in the EID-to-RLOC Map-Cache).
[major] Please use the names in the packet formats: indicate which is
the "Source Map-Version" and which the "Dest Map-Version".
...
154 3. Definitions of Terms
156 This document uses terms already defined in the main LISP
157 specification ([I-D.ietf-lisp-rfc6830bis],
158 [I-D.ietf-lisp-rfc6833bis]). Here, we define the terms that are
159 specific to the Map-Versioning mechanism. Throughout the whole
160 document, Big Endian bit ordering is used.
[major] Please avoid redefining terms that are already defined
elsewhere. Changes in either (even if editorial) may cause the
documents to fall out of sync. If you want to call attention to
specific terms, please point at the original definition or a specific
section.
For example:
Map-Version Number: as defined in §7.
162 Map-Version number: An unsigned 12-bit integer is assigned to an
163 EID-to-RLOC mapping, excluding the value 0 (0x000).
[major] Beyond being a 12-bit integer, this definition doesn't say
what the Map-Version number is. §7 contains a much better
description.
165 Null Map-Version: The 12-bit null value of 0 (0x000) is not used as
166 a Map-Version number. It is used to signal that no Map-Version
167 number is assigned to the EID-to-RLOC mapping.
[] Suggestion>
Null Map-Version: A Map-Version number with a value of 0x000 (zero),
used to signal that no Map-Version number is assigned to the
EID-to-RLOC mapping (Section 4.1).
169 Source Map-Version number: This Map-Version number of the EID-to-
170 RLOC mapping is used to select the source address (RLOC) of the
171 outer IP header of LISP-encapsulated packets.
[major] This definition describes what the Source Map-Version number
is used for, but not what it is. Also, the definition in §6 is
different from the one here -- it is close, but not the same. Please
define terminology in only one place. It seems to me that leaving
this definition up to §6 would be best.
173 Destination Map-Version number: This Map-Version number of the EID-
174 to-RLOC mapping is used to select the destination address (RLOC) of
175 the outer IP header of LISP-encapsulated packets.
[major] The packet format in rfc6830bis uses "Dest Map-Version"
instead of "Destination Map-Version". Please use the same terminology
in the packet format and throughout the document.
[major] Same comment as above: it describes what it's used for, not
what it is. There's a different definition in §6.
177 4. EID-to-RLOC Map-Version Number
179 The EID-to-RLOC Map-Version number consists of an unsigned 12-bit
180 integer. The version number is assigned on a per-mapping basis,
181 meaning that different mappings have a different version number,
182 which is also updated independently. An update in the version number
183 (i.e., a newer version) consists of incrementing by one the older
184 version number.
[major] "incrementing by one"
There's an exception in the case where V1+1 would result in 0, right?
Please mention it.
I later found that the last paragraph in §4.1 explains this exception.
Please point to if from here, or move the paragraph to this section.
Note that the text in §4.1 normatively requires (MUST) the increment,
but the description here doesn't use normative language. Please be
consistent.
...
212 Map-version numbers are assigned to mappings by configuration. The
213 initial Map-Version number of a new EID-to-RLOC mapping SHOULD be
214 assigned randomly, but it MUST NOT be set to the Null Map-Version
215 value (0x000), because the Null Map-Version number has a special
216 meaning (see Section 4.1).
[major] "Map-version numbers are assigned to mappings by
configuration. The initial Map-Version number of a new EID-to-RLOC
mapping SHOULD be assigned randomly..."
This sounds like a contradiction: configure, but make it random. I
assume that you mean that manual configuration may be the exception.
Suggestion>
The initial Map-Version number of a new EID-to-RLOC mapping SHOULD be
assigned randomly; it MUST NOT be set to the Null Map-Version value
(0x000) (see Section 4.1). Optionally, the initial Map-Version number
may be configured.
...
224 4.1. The Null Map-Version
[] The comments below indicate that there are multiple places that
overlap with this section. The text from this section may be
relocated (and clarifying actions taken) to make the document clearer.
This section could then be eliminated.
Paragraph 1 could be moved to §6.
Paragraph 2 could be moved to §5/§5.1/§5.2.
Paragraph 3 could be moved to §7.
Paragraph 4 could be moved to §4.
226 The value 0x000 (zero) is not a valid Map-Version number indicating
227 the version of the EID-to-RLOC mapping. Such a value is used for
228 special purposes and is named the Null Map-Version number.
230 The Null Map-Version MAY appear in the LISP-specific header as either
231 a Source Map-Version number (cf. Section 5.2) or a Destination Map-
232 Version number (cf. Section 5.1). When the Source Map-Version
233 number is set to the Null Map-Version value, it means that no map
234 version information is conveyed for the source site. This means that
235 if a mapping exists for the source EID in the EID-to-RLOC Map-Cache,
236 then the ETR MUST NOT compare the received Null Map-Version with the
237 content of the EID-to-RLOC Map-Cache. When the Destination Map-
238 Version number is set to the Null Map-Version value, it means that no
239 map version information is conveyed for the destination site. This
240 means that the ETR MUST NOT compare the value with the Map-Version
241 number of the mapping for the destination EID present in the EID-to-
242 RLOC Database.
[major] "Null Map-Version MAY appear"
s/MAY/may
This is a statement of fact, not a Normative statement.
[nit] s/cf. //g
[minor] Please put a forward reference to §5.1/§5.2 where "MUST NOT
compare" is used above. §5.1/§5.2 don't use "compare" as part of
their specification, but pointing to them should keep us from changing
the language here.
244 The other use of the Null Map-Version number is in the Map Records,
245 which are part of the Map-Request, Map-Reply, and Map-Register
246 messages (defined in [I-D.ietf-lisp-rfc6833bis]). Map Records that
247 have a Null Map-Version number indicate that there is no Map-Version
248 number associated with the mapping. This means that LISP-
249 encapsulated packets destined to the EID-Prefix referred to by the
250 Map Record MUST either not contain any Map-Version numbers (V bit set
251 to 0) or, if they contain Map-Version numbers (V bit set to 1), then
252 the destination Map-Version number MUST be set to the Null Map-
253 Version number. Any value different from zero means that Map-
254 Versioning is supported and MAY be used.
[] See comments in §7 about the requirements in this paragraph.
[nit] s/(defined in [I-D.ietf-lisp-rfc6833bis])/[I-D.ietf-lisp-rfc6833bis]/g
[major] "Any value different from zero means that Map-Versioning is
supported and MAY be used."
256 The fact that the 0 value has a special meaning for the Map-Version
257 number implies that, when updating a Map-Version number because of a
258 change in the mapping, if the next value is 0, then the Map-Version
259 number MUST be incremented by 2 (i.e., set to 1 (0x001), which is the
260 next valid value).
[] See my comment in §4 about this exception.
262 5. Dealing with Map-Version Numbers
...
272 To each mapping, a version number is associated and changes each time
273 the mapping is changed. Note that Map-Versioning does not introduce
274 new problems concerning the coordination of different ETRs of a
275 domain. Indeed, ETRs belonging to the same LISP site must return for
276 a specific EID-prefix the same mapping, including the same Map-
277 Version number. This is orthogonal to whether or not Map-Versioning
278 is used. The synchronization problem and its implications on the
279 traffic are out of the scope of this document.
[] See my comment in §7 about leaving this out of scope and the
requirement from rfc6833bis.
...
304 If one or both of the above conditions do not hold, the ETR can send
305 a Map-Request either to make the ITR aware that a new mapping is
306 available (see Section 5.1) or to update the mapping in the local
307 EID-to-RLOC Map-Cache (see Section 5.2).
[major] Should this behavior be Normative (MUST/SHOULD)? The text
currently says that "the ETR can send"; if the text doesn't require
(or at least recommend) an action then it looks like this document
just talks about carrying extra numbers around that don't serve a
specific purpose. I believe that §10 makes a good case for an action
to be specified.
309 5.1. Handling Destination Map-Version Number
311 When an ETR receives a packet, the Destination Map-Version number
312 relates to the mapping for the destination EID for which the ETR is
313 an RLOC. This mapping is part of the ETR EID-to-RLOC Database.
314 Since the ETR is authoritative for the mapping, it has the correct
315 and up-to-date Destination Map-Version number. A check on this
316 version number can be done, where the following cases can arise:
[major] "A check on this version number can be done..." Same comment
as above: Should this behavior be Normative (MUST/SHOULD)?
...
323 2. The packet arrives with a Destination Map-Version number greater
324 (i.e., newer) than the one stored in the EID-to-RLOC Database.
325 Since the ETR is authoritative on the mapping, meaning that the
326 Map-Version number of its mapping is the correct one, this
327 implies that someone is not behaving correctly with respect to
328 the specifications. In this case, the packet carries a version
329 number that is not valid; otherwise, the ETR would have the same
330 number, and the packet SHOULD be silently dropped.
[minor] The "otherwise" in this last sentence gives the impression
that the packet is dropped "otherwise" (i.e. when the version is not
greater).
Suggestion>
In this case, the packet carries a version number that is not valid
and the packet SHOULD be silently dropped.
[major] When is it ok for the packet not to be dropped? Why is this
action recommended and not required?
332 3. The packets arrive with a Destination Map-Version number smaller
333 (i.e., older) than the one stored in the EID-to-RLOC Database.
334 This means that the ITR sending the packet has an old mapping in
335 its EID-to-RLOC Map-Cache containing stale information. The ETR
336 MAY choose to normally process the encapsulated datagram
337 according to [I-D.ietf-lisp-rfc6830bis]; however, the ITR sending
338 the packet has to be informed that a newer mapping is available.
339 This is done with a Map-Request message sent back to the ITR.
340 The Map-Request will either trigger a Map-Request back using the
341 Solicit-Map-Request (SMR) bit or it will piggyback the newer
342 mapping. These are not new mechanisms; how to use the SMR bit or
343 how to piggyback mappings in Map-Request messages is already
344 described in [I-D.ietf-lisp-rfc6833bis]. One feature introduced
345 by Map-Version numbers is the possibility of blocking traffic not
346 using the latest mapping. Indeed, after a certain number of
347 retries, if the Destination Map-Version number in the packets is
348 not updated, the ETR MAY drop packets with a stale Map-Version
349 number while limiting the rate of Map-Request messages. This is
350 because either the ITR is refusing to use the mapping for which
351 the ETR is authoritative, or (worse) it might be some form of
352 attack.
[major] (Related to the last comment in §5.) "the ITR sending the
packet has to be informed that a newer mapping is available"
"has to be informed" sounds like a requirement. Should this action be
Normative?
[minor] If you're going to point at rfc6833bis anyway, don't go into
unnecessary detail.
OLD>
This is done with a Map-Request message sent back to the ITR.
The Map-Request will either trigger a Map-Request back using the
Solicit-Map-Request (SMR) bit or it will piggyback the newer
mapping. These are not new mechanisms; how to use the SMR bit or
how to piggyback mappings in Map-Request messages is already
described in [I-D.ietf-lisp-rfc6833bis].
NEW>
This is done with a Map-Request message sent back to the ITR, as
specified in [I-D.ietf-lisp-rfc6833bis].
[major] "after a certain number of retries...the ETR MAY drop packets"
If this is a Normative action, then the number of retries should be
indicated or at least suggested. §5.3/rfc6833bis mentions this:
Map-Requests MUST be rate-limited to 1 per second per EID-prefix.
After 10 retransmits without receiving the corresponding Map-Reply
the sender MUST wait 30 seconds.
Would 10 reties be appropriate in this case?
[major] "ETR MAY drop packets"
Why is this an optional action and not required? What should the ETR
take into account when deciding if the packets are to be dropped or
not?
354 The rule in the third case MAY be more restrictive. If the mapping
355 has been the same for a period of time as long as the Time To Live
356 (TTL) (defined in [I-D.ietf-lisp-rfc6833bis]) of the previous version
357 of the mapping, all packets arriving with an old Map-Version SHOULD
358 be silently dropped right away without issuing any Map-Request. Such
359 action is permitted because if the new mapping with the updated
360 version number has been unchanged for at least the same time as the
361 TTL of the older mapping, all the entries in the EID-to-RLOC Map-
362 Caches of ITRs must have expired. Hence, all ITRs sending traffic
363 should have refreshed the mapping according to
364 [I-D.ietf-lisp-rfc6833bis]. If packets with old Map-Version numbers
365 are still received, then either someone has not respected the TTL or
366 it is a form of spoof/attack. In both cases, this is not valid
367 behavior with respect to the specifications and the packet SHOULD be
368 silently dropped.
[major] s/MAY be more restrictive/may be more restrictive
This is just a statement of fact, not a normative one.
[minor] "the Time To Live (TTL) (defined in
[I-D.ietf-lisp-rfc6833bis]) of the previous version"
I wasn't sure if you meant that the TTL was defined in rfc6833bis or
if a specific value was defined there. But after looking at
rfc6833bis I am guessing that you mean something like this:
OLD>
If the mapping has been the same for a period of time as long as
the Time To Live (TTL) (defined in [I-D.ietf-lisp-rfc6833bis])
of the previous version of the mapping, ...
NEW>
If the Record TTL of the previous mapping has already expired, ...
[major] "all packets...SHOULD be silently dropped"
Why is this action recommended and not required? When is it ok for
the the packets to not be dropped?
[minor] s/In both cases, this is not valid behavior with respect to
the specifications and the packet SHOULD be silently dropped./In both
cases, this is not valid behavior.
Please don't repeat the specification.
370 LISP-encapsulated packets with the V-bit set, when the original
371 mapping in the EID-to-RLOC Database has the version number set to the
372 Null Map-Version value, MAY be silently dropped. As explained in
373 Section 4.1, if an EID-to-RLOC mapping has a Null Map-Version, it
374 means that ITRs, using the mapping for encapsulation, MUST NOT use a
375 Map-Version number in the LISP-specific header.
[major] "MAY be silently dropped" -- "As explained in Section 4.1..."
Please look at the related comments in §4.1/§7 about the required
behavior. BTW, the reference should be to §7.
If there is a required (MUST) behavior in §4.1/§7, why is the behavior
specified here only optional (MAY)? What should the ETR take into
account when making the decision?
Also, please just refer to other sections and don't repeat normative
language here.
377 For LISP-encapsulated packets with the V-bit set, when the original
378 mapping in the EID-to-RLOC Database has the version number set to a
379 value different from the Null Map-Version value, a Destination Map-
380 Version number equal to the Null Map-Version value means that the
381 Destination Map-Version number MUST be ignored.
[] I find this sentence (and the first one in the previous paragraph)
hard to read.
Suggestion>
If the mapping in the EID-to-RLOC Database has a non-zero version
number, LISP-encapsulated packets with the V-bit set and a Null
Map-Version in the Dest Map-Version field MUST be ignored.
[minor] "MUST be ignored"
I'm assuming that ignoring a packet is the same as dropping it, right?
The other instances talked about dropping, please be consistent.
383 5.2. Handling Source Map-Version Number
...
391 1. The packet arrives with the same Source Map-Version number as
392 that stored in the EID-to-RLOC Map-Cache. This is the correct
393 regular case. The ITR has in its EID-to-RLOC Map-Cache an up-to-
394 date copy of the mapping. No further actions are needed.
[minor] s/ITR/ETR
396 2. The packet arrives with a Source Map-Version number greater
397 (i.e., newer) than the one stored in the local EID-to-RLOC Map-
398 Cache. This means that the ETR has in its EID-to-RLOC Map-Cache
399 a stale mapping that needs to be updated. A Map-Request SHOULD
400 be sent to get the new mapping for the source EID. This is a
401 normal Map-Request message sent through the mapping system and
402 MUST respect the specifications in [I-D.ietf-lisp-rfc6833bis],
403 including rate-limitation policies.
[major] "Map-Request SHOULD be sent"
Why is this action recommended and not required? When is it ok for
the ETR to not send a Map-Request (in response to this event)?
[minor] The last sentence, specially the part requiring respect for
rfc6833bis is not needed. Please take it out.
405 3. The packet arrives with a Source Map-Version number smaller
406 (i.e., older) than the one stored in the local EID-to-RLOC Map-
407 Cache. Such a case is not valid with respect to the
408 specifications. Indeed, if the mapping is already present in the
409 EID-to-RLOC Map-Cache, this means that an explicit Map-Request
410 has been sent and a Map-Reply has been received from an
411 authoritative source. Assuming that the mapping system is not
412 corrupted, the Map-Version in the EID-to-RLOC Map-Cache is the
413 correct one, while the one carried by the packet is stale. In
414 this situation, the packet MAY be silently dropped.
[] "Assuming that the mapping system is not corrupted"
I don't think this text adds anything to the specification -- just
opens up questions of mapping system consistency, etc.. which we don't
want to address in this document. Please take that part out.
[major] "the packet MAY be silently dropped"
Why is this action optional and not required? The rest of the
paragraph talks about how this "case is not valid with respect to the
specifications" -- I then don't understand why it would only be
optional to drop the packet.
...
419 For LISP-encapsulated packets with the V-bit set, if the Source Map-
420 Version number is the Null Map-Version value, it means that the
421 Source Map-Version number MUST be ignored.
[] There is related text in §4.1. Please specify actions only once.
423 6. LISP Header and Map-Version Numbers
425 In order for the versioning approach to work, the LISP-specific
426 header has to carry both the Source Map-Version number and
427 Destination Map-Version number. This is done by setting the V-bit in
428 the LISP-specific header as specified in [I-D.ietf-lisp-rfc6830bis].
429 When the V-bit is set and the N bit is reset (0), the low-order 24
430 bits of the first longword are used to transport both the source and
431 destination Map-Version numbers. In particular, the first 12 bits
432 are used for the Source Map-Version number and the second 12 bits for
433 the Destination Map-Version number.
[minor] "... as specified in [I-D.ietf-lisp-rfc6830bis]. When the
V-bit is set and the N bit is reset (0), the low-order 24 bits of the
first longword are used to transport both the source and destination
Map-Version numbers. In particular, the first 12 bits are used for
the Source Map-Version number and the second 12 bits for the
Destination Map-Version number."
rfc6830bis also shows (§5.3) that the E-bit is not set. That makes
this description incomplete. Instead of trying to repeat what
rfc6830bis already says, simply point at it. Also, a picture is worth
a thousand words -- in this case it can replace cumbersome
descriptions:
Suggestion>
... as specified in [I-D.ietf-lisp-rfc6830bis]. The Source
Map-Version and Dest Map-Version are included as shown in
Figure x.
435 Below is an example of a LISP header carrying version numbers.
[major] s/LISP header/LISP-specific header
Note the definition of "LISP header" in rfc6830bis:
LISP Header: LISP header is a term used in this document to refer
to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
specific 8-octet header that follow the UDP header and that an ITR
prepends or an ETR strips.
437 0 1 2 3
438 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
440 / |N|L|E|V|I|R|K|K| Source Map-Version |Destination Map-Version|
441 LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
442 \ | Instance ID/Locator Status Bits |
443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[minor] Please add a figure number/title to this and all the figures.
[minor] s/Locator Status Bits/Locator-Status-Bits/g
...
450 Destination Map-Version number (12 bits): Map-Version of the mapping
451 used by the ITR to select the RLOC present in the "Destination
452 Routing Locator" field. Section 5.1 describes how to set this
453 value on transmission and handle it on reception.
[minor] The description in §5.1 says that "the Destination Map-Version
number relates to the mapping for the destination EID for which the
ETR is an RLOC." I know that this description is equivalent to "the
mapping used by the ITR to select the RLOC present in the "Destination
Routing Locator" field", but they are different. It might be worth
spending a paragraph or two in the Introduction summarizing how LISP
works. Or, even better, put an Informative reference to
lisp-introduction.
Suggestion (for the Introduction)>
[lisp-introduction] describes the architecture of the Locator/ID
Separation Protocol. It is expected that the reader is familiar
with this introductory document.
...
460 7. Map Record and Map-Version
462 To accommodate the proposed mechanism, the Map Records that are
463 transported in Map-Request/Map-Reply/Map-Register messages need to
464 carry the Map-Version number as well. For this purpose, the 12 bits
465 before the EID-AFI field in the Record that describes a mapping are
466 used (see [I-D.ietf-lisp-rfc6833bis] and reported here as an example.
[minor] "For this purpose, the 12 bits before the EID-AFI field in the
Record that describes a mapping are used (see
[I-D.ietf-lisp-rfc6833bis] and reported here as an example."
The description is again cumbersome ("12 bits before") -- simply point
at the figure. Also, I'm not sure what the example part means.
Suggestion>
For reference, the Map Register (specified in [I-D.ietf-lisp-rfc6833bis])
is presented in Figure y.
468 0 1 2 3
469 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
470 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
471 | | Record TTL |
472 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
473 R | Locator Count | EID mask-len | ACT |A| Reserved |
474 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
475 c | Rsvd | Map-Version Number | EID-Prefix-AFI |
476 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
477 r | EID-Prefix |
478 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
479 | /| Priority | Weight | M Priority | M Weight |
480 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
481 | o | Unused Flags |L|p|R| Loc-AFI |
482 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
483 | \| Locator |
484 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
486 Map-Version Number: Map-Version of the mapping contained in the
487 Record. As explained in Section 4.1, this field can be zero (0),
488 meaning that no Map-Version is associated to the mapping; hence,
489 packets that are LISP encapsulated using this mapping MUST NOT
490 contain Map-Version numbers in the LISP-specific header, and the
491 V-bit MUST be set to 0.
[major] This description is not the same as what is specified in §4.1
or the definition in §5.4/rfc6833bis. Please define this term only
once!
(A) "Section 4.1...hence, packets that are LISP encapsulated using
this mapping MUST NOT contain Map-Version numbers in the LISP-specific
header, and the V-bit MUST be set to 0."
The required actions here are different from the actions required in §4.1:
This means that LISP-encapsulated packets destined to the EID-Prefix
referred to by the Map Record MUST either not contain any Map-Version
numbers (V bit set to 0) or, if they contain Map-Version numbers (V
bit set to 1), then the destination Map-Version number MUST be set to
the Null Map-Version number. Any value different from zero means that
Map-Versioning is supported and MAY be used.
Note that "MUST either" is not a valid construct because it doesn't
reflect a requirement, it indicates an option.
[B] §5.4/rfc6833bis contains a different definition of this field:
Map-Version Number: When this 12-bit value is non-zero, the Map-
Reply sender is informing the ITR what the version number is for
the EID record contained in the Map-Reply. The ETR can allocate
this number internally but MUST coordinate this value with other
ETRs for the site. When this value is 0, there is no versioning
information conveyed. The Map-Version Number can be included in
Map-Request and Map-Register messages. See Map-Versioning
[I-D.ietf-lisp-6834bis] for more details.
The text in §5 is vague about the required coordination mentioned in
rfc6883bis. In fact, it mentions this: "The synchronization problem
and its implications on the traffic are out of the scope of this
document." This is a significant problem!
rfc6833bis requires (MUST) the coordination and points to this
document for more details. However, this document declares the
problem out of scope.
To make it worst, rfc6830bis both leaves synchronization out of scope
*and* specifies a window for doing so: "synchronization protocol is
out-of-the-scope of this document, but MUST keep ETRs synchronized
within a 1 minute window."
How can the requirements in rfc6833bis/rfc6830bis be satisfied if the
mechanism is out of scope?
Personally, I am ok with the synchronization between ETRs to be out of
scope. I need you to the come up with specific language that gets the
specs in sync. That will require eliminating the normative language
and possibly updating rfc6830bis and rfc6833bis.
493 This packet format works perfectly with xTRs that do not support Map-
494 Versioning, since they can simply ignore those bits.
[nit] By "works perfectly" I assume you mean something less
"marketing" like "is backwards compatible".
496 8. Benefits and Case Studies for Map-Versioning
[] I suggest this section be moved to an appendix.
...
502 8.1. Map-Versioning and Unidirectional Traffic
...
521 In the case of the ITR, the ITR is able to put both the source and
522 destination version number in the LISP header, since the Source Map-
523 Version number is in the ITR's database, while the Destination Map-
524 Version number is in the ITR's cache.
[nit] NEW>
An ITR is able to put both the source and destination version
numbers in the LISP header since the Source Map-Version number
is in its database while the Destination Map-Version number is
in its cache.
526 In the case of the ETR, the ETR simply checks only the Destination
527 Map-Version number in the same way as that described in Section 5,
528 ignoring the Source Map-Version number.
[nit] NEW>
The ETR checks only the Dest Map-Version number as described
in Section 5, ignoring the Source Map-Version number.
...
612 8.4. Map-Version Additional Use Cases
[] This use case, and specifically "a lightweight implementation of
LISP" seems inline with the experimental version of this document, but
not the current form. Please remove it.
If there is a document describing that "lightweight implementation"
then a reference can be added.
...
628 9. Security Considerations
630 Attackers can try to trigger a large number of Map-Requests by simply
631 forging packets with random Map-Versions. The Map-Requests are rate-
632 limited as described in [I-D.ietf-lisp-rfc6833bis]. With Map-
633 Versioning it is possible to filter invalid version numbers before
634 triggering a Map-Request, thus helping to reduce the effects of DoS
635 attacks. However, it might not be enough to really protect from a
636 DDoS attack.
[] Given what is specified here, are there other things that an
attacker could do? For example, just thinking out loud, not sure if
these are possible:
- Can an attacker glean at headers and reuse the version numbers to
generate additional traffic (to overload a node, for example) with a
header that looks to be correct?
- If the network is configured to use Map-Versioning but a rogue node
decides to not use the V-bit, are there significant consequences? I
don't think to, just asking.
- Is there any significant information (topology, cache content, for
example) that could be gleaned from knowing the Map-Versions at
different xTRs? Besides the attack already mentioned, can an attacker
do anything else with this knowledge?
638 Robustness of the Map-Versioning mechanism leverages on a trusted
639 Mapping Distribution System. A thorough security analysis of LISP is
640 documented in [RFC7835].
[major] We shouldn't get into aspects of what "trusted Mapping
Distribution System" may be. Instead of this paragraph, let's add a
pointer to the base specs as the initial paragraph of this section.
Suggestion>
This document builds on the specification and operation of the
LISP control and data planes. The Security Considerations of
[I-D.ietf-lisp-rfc6830bis] and [I-D.ietf-lisp-rfc6833bis] apply.
642 As specified in [I-D.ietf-lisp-rfc6830bis], Map-Versioning MUST NOT
643 be used over the public Internet and SHOULD only be used in trusted
644 and closed deployments.
[major] Please don't specify things in two places! If specified in
rfc6830bis and this section points there anyway there's no need to
even mention it.
646 10. Deployment Considerations
...
692 The same problem can, however, arise without Map-Versioning, for
693 instance, if the two ITRs of Domain A send different Locator Status
694 Bits. In this case, either the traffic is disrupted if ETR B trusts
695 the Locator Status Bits, or if ETR B does not trust the Locator
696 Status Bits it will start sending Map-Requests to confirm each change
697 in reachability.
[major] "ETR B trusts...ETR B does not trust"
Instead of talking about "trust", which may not convey the appropriate
intent, please talk about "verification" (using the language in
rfc6830bis) and how the ETR can verify and avoid disruptions.
699 So far, LISP does not provide any specific synchronization mechanism
700 but assumes that synchronization is provided by configuring the
701 different xTRs consistently. The same applies for Map-Versioning.
702 If in the future any synchronization mechanism is provided, Map-
703 Versioning will take advantage of it automatically, since it is
704 included in the Record format, as described in Section 7.
[minor] Both §5/§7 talk about synchronization. Please consolidate
this topic in one place.
[EoR -09]
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
