[lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6833bis-26: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-rfc6833bis-26: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

It looks like an edit or two that was supposed to be in the -26 didn't make it
by accident, so sorry for the repeat comments; hopefully the writing work in
question will be easy to retrieve.

Other than that we're down to just a few remaining points, two of which
I believe should be trivial to resolve.


In Section 5.6 we say that "implementations of this spsecification SHOULD include
support for HMAC-SHA256-128+HKDF-SHA256 but section 9 says "implementation
MUST support HMAC-SHA256-128+HKDF-SHA256", which is internally inconsistent;
my understanding from a previous discussion with the authors was that
HMAC-SHA256-128+HKDF-SHA256 would be a SHOULD and it was HMAC-SHA256-128
that was MUST.

The condition for Map-Notify-Ack terminating Map-Notify retransmission
seems incomplete.  Specifically, we should only accept the
Map-Notify-Ack to stop retransmission if the authentication data validates
(and maybe that it uses the same Key-ID as the Map-Notify, though that
might be overkill).  So just "a Map-Notify-Ack is received by the
Map-Server with the same nonce" is not quite enough; we'd want to say
"an authenticated Map-Notify-Ack is received by the Map-Server with the same
nonce".

In Section 9:

                                                     The LISP-SEC
   protocol defines a mechanism for providing origin authentication,
   integrity, anti-replay, protection, and prevention of 'man-in-the-
   middle' and 'prefix overclaiming' attacks on the Map-Request/Map-
   Reply exchange.  [...]

I think this document provides anti-replay protection for the
Map-Request/Map-Reply exchange (by virtue of the single-use nonce), so
we should remove "anti-replay" from the list of features LISP-SEC provides
for the Map-Request/Map-Reply exchange.

I think we need greater clarity on the 'E' and 'M' bits in the ECM format;
are we perhaps defining them now in anticipation of future usage by
other documents (e.g., ones that define specific mapping system implementations)?
in particular (with quotes from my ballot position on the -24 for context):
>   E:    This is the to-ETR bit.  When set to 1, the Map-Server's
>         intention is to forward the ECM to an authoritative ETR.
>
> I think this needs to say more about which message flows this bit is
> defined for.  Presumably the ITR will never use it for sending an
> encapsulated Map-Request to a Map-Resolver, but there seem to be plenty of
> places where ECM wrapping is used.

IIUC, the main ECM-wrapped messages we consider in this document are
ITR-to-Map-Resolver Map-Requests and Map-Server-to-ETR Map-Requests.
Is it an invariant that the ECM 'E' and 'M' bits can never be set at the same time
(as they are only defined to have meaning for the different flows I list)?
In an off-list discussion I got a clarification that "The ETR bit is used so the
Map-Server knows that the entity registering is an xTR versus a SDN or other
type of controller that is registering mappings but doesn’t have a full LISP
protocol engine implementation and can’t send Map-Replies" which sounds like
it applies to a Map-Register ("is registering mappings") but I didn't think that
Map-Register was defined as a possible LCM to be in an ECM.  (Maybe I'm just
confused about that.)

The main thing I still don't understand here is: what entity is going to interpret
the E-bit and change behavior depending on its value?

>
>   M:    This is the to-MS bit.  When set to 1, a Map-Request is being
>         sent to a co-located Map-Resolver and Map-Server where the
>         message can be processed directly by the Map-Server versus the
>         Map-Resolver using the LISP-DDT procedures in [RFC8111].
>
> How does the sender know that its configured Map-Resolver is also a
> Map-Server?  It's unclear to me why this needs a bit in the message as
> opposed to just happening based on the attributes of the receiving
> Map-Server.

It sounds like this is only useful when the ECM contains a Map-Request
from ITR to Map-Resolver, but I don't know how an ITR would know to
(not) set this bit or what entity is going to change behavior depending
on the value of the bit.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[moving from DISCUSS to COMMENT based on explanation of this usage
being a common historical usage in the LISP community.  It still seems
needlessly ambiguous and confusing to me, though, but no response is
required, as we've discussed this already quite a bit and I just want to
stay "on the record" about it.]
There are many instances (some noted in my Comment) where a
bidirectional interaction between two xTRs is described, yet the peers are
identified as "ITR" and "ETR".  This is very confusing when the entity
named as "ITR" is described as performing ETR functionality, or vice versa;
pedagogically, it would be much better to use non-role-based names for the
entities while describing these exchanges.

[Also moving from DISCUSS to COMMENT]
I'm still a little nervous about the strong dependencies on lisp-sec and
6834bis that are not yet at IESG evaluation, but perhaps they are sufficiently
mature that I don't need to hold a Discuss point anymore to wait for them.

I got a request for more clarification on my previous remark:
% Section 8.1 says:
%    o  A Negative Map-Reply, with action code of ""Natively-Forward"", from
%       a Map-Server that is authoritative for an EID-Prefix that matches
%       the requested EID but that does not have an actively registered,
%       more-specific ID-prefix.
% This document provides no mechanism to establish that a Map-Server is
% authoritative for a given EID-Prefix, so this entire case is
% non-actionable.
% [ed. I think there may have been some previous discussion on this (e.g.,
% that might render it moot) but couldn't find it quickly]

I think that the "previous discussion" essentially entailed a LISP deployment
including some configuration information about which sites were allowed/expected
to have certain EID prefixes, so the "authoritative" here is just excluding
sites that are known to not be candidates.  That is, the deployment-specific
"authoritative" nature is essentially coming from configuration, if I understand
correctly.  So I didn't think that any further clarification was needed.

A few more other old comments with extra clarification as-needed; I'll
trim most of the comments from the -25.

Section 5.2
   EID mask-len:  This is the mask length for the EID-Prefix.

I see this got changed to add "in decimal" as a result to my earlier
comment, but I think my earlier comment was wrong and that change
should be reverted.  It doesn't make sense to measure a prefix length
in bytes, and we have explicit examples of the mask length for when
we need to limit to an exact IP (v4 or v6) address, which would allow
the reader to figure it out anyway.  Sorry for the extra churn (and noting
that the same thing occurs in a later section).

Section 5.6

Do you want to give a mnemonic for the 'I' bit?  I don't propose changing
its name, but if there was some extra word or two that would help someone
remember why it is the 'I' bit (as opposed to, say, the 'Q' bit) that would be helpful.

Section 5.7

   A Map-Server sends an unsolicited Map-Notify message (one that is not
   used as an acknowledgment to a Map-Register message) that follows the
   Congestion Control And Relability Guideline sections of [RFC8085].  A

This second clause ("that follows") is rather a non sequitur here; is the intent
something like "sends unsolicited Map-Notify messages in only conformance
with the guidelines from RFC 8085"?

Section 5.8

   An Encapsulated Control Message (ECM) is used to encapsulate control
   packets sent between xTRs and the mapping database system.

Some of the flag bit descriptions appear to describe usages that are or can
be entirely within the mapping system, so maybe tweak the wording to
"between xTRs and the mapping database system or internal to the mapping
database system"?

Section 6.1

   sender of an SMR-based Map-Request MUST be verified.  If an ITR
   receives an SMR-based Map-Request and the source is not in the
   Locator-Set for the stored Map-Cache entry, then the responding Map-
   Request MUST be sent with an EID destination to the mapping database
   system.  [...]

Based on our offline discussion about which messages go in which
direction between ITR and ETR, I think this would be more clear if it
did s/SMR-based Map-Request/SMR message/ (both times).