Hi John,
Thanks a lot for the very interesting discussion.
I am trimming the DISCUSS part in this thread and focusing on the COMMENTS.
You provided interesting input in the DISCUSS thread and I prefer focus on them
separately.
Please see inline for the comments.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I support Roman Danyliw's DISCUSS position.
>
> I have a number of further questions and comments --
>
> 1. In §6.1:
>
> If an ETR receives LISP-encapsulated packets with the V-bit
> set, when the original mapping in the EID-to-RLOC Database has the
> version number set to the Null Map-Version value, then those packets
> MUST be silently dropped.
>
> What does “original” mean in this context? Couldn’t the mapping in the db once
> have had a value but in a later revision, had its value changed to the null
> value? Presumably in such a situation packets would be lost until the ITR
> decided to issue a new map-request.
>
> 2. In §7.1 (3):
>
> According to rate
> limitation policy defined in [I-D.ietf-lisp-rfc6833bis] for Map-
> Request messages, after 10 retries Map-Requests are sent every 30
> seconds, if in the meantime the Dest Map-Version number in the
> packets is not updated, the ETR SHOULD drop packets with a stale
> Map-Version number.
>
> What exactly is “the meantime”? Does that mean “after 10 retries”? After 30
> seconds? Basically, what precisely is the grace period extended to the ITR
> have
> to come into compliance before being blocked? This seems important to be clear
> about -- even if the clarity is in the form of "it's
> implementation-dependent".
Yes, it has to be more precise.
The text is updated as:
According to rate limitation
policy defined in [I-D.ietf-lisp-rfc6833bis] for Map-Request
messages, after 10 retries Map-Requests are sent every 30
seconds, if after the first 10 retries the Dest Map-Version
number in the packets is not updated, the ETR SHOULD drop packets
with a stale Map-Version number.
Do you consider it sufficiently clear?
>
> 3. In §7.1, final paragraph:
>
> LISP-encapsulated packets cannot transport a Dest Map-Version number
> equal to the Null Map-Version number, because in this case the ETR is
> signaling that Map-Version numbers are not used for the mapping of
> the destination EID (see Section 6.1).
>
> Considering that the Null Map-Version number is just the distinguished value
> 0,
> the first clause is prima facie wrong -- it's possible to encode 0 in that
> field. I think what you mean is something more along the lines of
>
> It is a protocol violation for LISP-encapsulated packets to contain a
> Dest Map-Version number equal to the Null Map-Version number, see
> Section 6.1.
>
> Please don't try to explain it again in-line as you've done, it just confuses
> the reader (well, it confused me!). Instead, refer them back to the place
> where
> you specified the rule.
Thanks. I will use your sentence.
I have indeed tendency to repeat stuff, which is not a good.
>
> It does seem unfortunate that in this case, it's not possible to include a
> Source Map-Version number, even if that would be helpful to do, since the V
> bit
> is required to be set to 0 and covers both Source and Dest.
>
I do agree, however, point is that you are not able to distinguish between an
ETR that supports versioning but does not use it and another that does not
support it, hence the choice that has been made.
> 4. §7.1 (3), nit: s/The packets arrive/The packet arrives/
Thanks. Will be fixed.
>
> 5. In §7.1 and §7.2:
>
> A check on this version number SHOULD be
> done, where the following cases can arise:
>
> and
>
> If the ETR has an entry in its EID-to-RLOC
> Map-Cache for the source EID, then a check SHOULD be performed and
> the following cases can arise:
>
> What are the cases under which the check can be omitted? Please consider
> adding
> discussion about those cases. Alternately, consider making the SHOULD a MUST
> if
> there are no such cases.
Yes, we received already the same comment. MUST is more appropriate and will be
used.
>
> 6. In §7.2:
>
> 3. The packet arrives with a Source Map-Version number smaller
> (i.e., older) than the one stored in the local EID-to-RLOC Map-
> Cache. Such a case is not valid with respect to the
> specifications.
>
> The final sentence ("not valid") seems like it must be wrong: consider for
> example the case of out-of-order packets. Other scenarios also exist, such as
> transient non-synchronization between ETRs during convergence. I notice that
> §9
> talks about the lack of synchronization mechanisms in LISP, other than
> diligent
> consistency of configuration. So, I guess there's a good chance that
> "convergence" means "someone updating mapping configurations by hand" and so
> version skew could exist for human-scale periods of time. Of greatest concern
> is if "human-scale periods of time" means "hours or days" in the case where a
> mistake with operational procedures leaves the hand-configured databases on
> two
> ETRs out of sync with one another.
>
> I guess a minimum fix would be to simply cut the wrong sentence and slightly
> re-word, e.g.:
>
> 3. The packet arrives with a Source Map-Version number smaller
> (i.e., older) than the one stored in the local EID-to-RLOC Map-
> Cache. Note that if the mapping is already present in the
> EID-to-RLOC Map-Cache, this means that an explicit Map-Request
> has been sent and a Map-Reply has been received from an
> authoritative source. In this situation, the packet SHOULD be
> silently dropped. Operators can configure exceptions to this
> recommendation, which are outside the scope of this document.
That reads much much better. Thanks I will use your suggestion.
>
> 7. In §7.2:
>
> If the ETR does not have an entry in the EID-to-RLOC Map-Cache for
> the source EID, then the Source Map-Version number MUST be ignored.
>
> I think it would be nice to have an xref to §A.1, where the reason for this is
> explained. Otherwise it seems rather arbitrary.
Yes, this is a good idea, also in light of the comment you made for §A.1.
Will add a forward reference.
>
> 8. In §8:
>
> I see that in -12 you cut the text that in -11 used to say
>
> Map-Versioning MUST NOT be used over the public Internet and SHOULD
> only be used in trusted and closed deployments.
>
> I note that the requirement continues to exist however, since normative
> reference draft-ietf-lisp-rfc6830bis-38 §4.1 says
>
> Several of the mechanisms in this document are intended for
> deployment in controlled, trusted environments, and are insecure for
> use over the public Internet. In particular, on the public internet
> xTRs:
> ...
> * MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
> as described in Section 13 to update the EID-to-RLOC Mappings.
> Instead relying solely on control-plane methods.
>
> Thus it still seems to me that the questions others raised about this
> requirement may be relevant.
>
> So, I question whether cutting the text is the right way to fix the concerns.
> It makes sense in an Experimental document, but perhaps not in a Standards
> Track one.
The text you refer to has not been just cut out. It has been moved to the first
paragraph of the section.
The specific text is now:
Map-Versioning MUST NOT be used over the public Internet and
MUST only be used in trusted and closed deployments.
And the whole first paragraph is:
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 and,
as such, Map-Versioning MUST NOT be used over the public Internet and
MUST only be used in trusted and closed deployments. A thorough
security analysis of LISP is documented in [RFC7835].
I believe this is inline with what you are saying, isn’t it?
>
> 9. In §9:
>
> LISP requires ETRs to provide the same mapping for the same EID-
> Prefix to a requester.
>
> What does this mean? Same as what? I guess maybe what you mean here is "LISP
> requires multiple ETRs within the same site to provide identical mappings for
> a
> given EID-Prefix"? If so, please say that (or something else clearer than
> what's there now). If not, please help?
Thanks, I find your suggested sentence very clear and I will use it in the next
revision of the document.
>
> 10. In §A.1:
>
> The ETR checks only the Dest Map-Version number as described in
> Section 7, ignoring the Source Map-Version number.
>
> I would rewrite as
>
> The ETR checks only the Dest Map-Version number,
> ignoring the Source Map-Version number as specified in
> the final sentence of Section 7,.
>
Thanks. The text will be fixed as you suggest.
> 11. In §A.2:
>
> LISP interworking
> defines three techniques to make LISP sites and non-LISP sites,
> namely Proxy-ITR, LISP-NAT, and Proxy-ETR.
>
> This isn't a complete sentence. I guess what you mean is something like "LISP
> interworking defines three techniques to allow communication between LISP and
> non-LISP sites"?
Yes, indeed. The text will be changed as you suggest.
>
> 12. In §A.2.1:
>
> With this setup, LISP Domain A is able to check whether the PITR is
> using the latest mapping.
>
> First, how does Domain A check this?
> Second, the latest mapping for what? I
> suppose you might mean something like "Domain A is able to check whether the
> PITR is using the latest mapping for the destination EID, by inspecting the
> Destination Map-Version as detailed in Section 7.1"?
The ETR will look at the Dest Map-Version Number as described in 7.1, if the
PITR is using an old mapping an SMR is triggered.
For clarity text can been changed in:
With this setup, LISP Domain A is able to check whether the PITR is
using the most up-to-date mapping. The Proxy ITR will put in the Dest Map-
Version Number of the LISP-specific header the version number of the
mapping it is using for encapsulation, the ETR A can use such value
as defined in Section 7.1.
DO you think is sufficiently clear?
>
> 13. In §A.2.3:
>
> With this setup, the Proxy-ETR, by looking at the Source Map-Version
> Number, is able to check whether the mapping has changed.
>
> Again, what mapping, and how? I guess it must be the source EID. (The version
> 12 text, which I've quoted here, makes that clearer, although it would still
> be
> even clearer to write "... check whether the Source EID-to-RLOC mapping has
> changed.") Why does the ETR care about that? I guess there's the assumption it
> might be an ITR/ETR passing traffic bidirectionally, in which case the source
> EID might be useful, but if that's the reason then some words to that effect
> would help.
It is more about validating where the packet comes from.
In the example, traffic coming from the LISP domain has to be LISP-encapsulated
with RLOCS belonging to that domain.
To perform that check the Proxy ETR needs the mapping of that domain and
version number can signal a change.
The text can be updated as follows:
With this setup, the Proxy-ETR, by looking at the Source Map-Version
Number, is able to check whether the mapping of the source EID has
changed. This is useful to perform source validation. In the
example above, traffic coming from LISP domain has to be LISP-
encapsulated with a source address being an RLOC of the domain. The
Proxy ETR can retrieve the mapping associated to the LISP domain and
check if incoming LISP-encapsulated traffic is arriving from a valid
RLOC. A change in the RLOC set that can be used as source addresses
can be signaled via the version number, with the Proxy ETR able to
request the latest mapping if necessary as described in Section 7.2.
Do you consider this sufficiently clear?
Thanks again for the review and suggestions.
Let me know what do you think about the above fixes for the COMMENTS part.
Ciao
L.
>
>
>
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
