Subject: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Sep 2018 20:44:24 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-rfc6830bis-20: 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-rfc6830bis/

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

I have grave concerns about the suitability of LISP as a whole, in its
present form, for advancement to the Standards-Track.  While some of my
concerns are not specific to this document, as the core protocol
(data-plane) spec, it seems an appropriate place to attach them to.

I am told, out of band, that the intended deployment model is no longer to
cover the entire Internet (c.f. the MISSREF-state
draft-ietf-lisp-introduction's "with LISP, the dge of the Internet and the
core can be logically separated and interconnected by LISP-capable
routers", etc.), and that full Internet-scale operation is no longer a
goal.  However, since that does not seem to be reflected in the current
batch of documents up for IESG review, I am forced to ballot on them
"as-is", namely as targetting global Internet deployment.  The requirements
placed on the mapping system are so stringent so as to be arguably
unachievable at Internet-scale, though that arguably has more of an
interaction with the control-plane than the data-plane.  It's still in
scope here, though, as part of the overall description of the protocol
flow.

There are an almost innumerable number of downgrade attacks possible, and
the control-plane and data-plane security mechanisms are not normative
dependencies of the current corpus of documents, and as such are not up for
consideration as mitigating the security concerns with the core documents.

Section 3 defines the EID-to-RLOC Datbaase:

   EID-to-RLOC Database:   The EID-to-RLOC Database is a global
      distributed database that contains all known EID-Prefix-to-RLOC
      mappings.  Each potential ETR typically contains a small piece of
      the database: the EID-to-RLOC mappings for the EID-Prefixes
      "behind" the router.  These map to one of the router's own
      globally visible IP addresses.  Note that there MAY be transient
      conditions when the EID-Prefix for the site and Locator-Set for
      each EID-Prefix may not be the same on all ETRs.  This has no
      negative implications, since a partial set of Locators can be
      used.

No compelling architecture for a trustworthy global distributed database
has been presented that I've seen so far, and LISP relies heavily on the
mapping system's database for its functionality.  I am concerned that so
many requirements are placed on the mapping system so as to be in effect
unimplementable, in which case it would seem that the architecture as a
whole (that is, for a global Internet-scale system) is not fit for purpose.

Section 4.1's Step (6) only mentions parsing "to check for format
validity".  I think it is appropriate to mention (and refer to) source
authentication checks as well, since bad Map-Reply data can allow all sorts
of attacks to occur.

There are some fairly subtle ordering requirements between the order of
entries in Map-Reply messages and the Locator-Status-Bits in data-plane
traffic (so that the semantic meaning of the status bits are meaningful),
which is only given a minimal treatment in the control-plane document.  The
need for synchronization in interpreting these bits should be mentioned
more prominently in the data-plane document as well.

The usage of the Instance ID does not seem to be adequately covered; from
what I've been able to pick up so far it seems that both source and
destination participants must agree on the meaning of an Instance ID, and
the source and destination EIDs must be in the same Instance.  This does
not seem like it is compatible with Internet scale, especially if there are
only 24 usable bits of Instance ID.

There seems to be a lot of intra-site synchronization requirements, notably
with respect to Map-Version consistency, the contents and ordering of
locator sets for EIDs in the site, etc.; the actual hard requirements for
synchronization within a site should be clearly called out, ideally in a
single location.

The security considerations attempt to defer substantially to the
threat-analysis in RFC 7835, which does not really seem like a complete
threat analysis and does not provide analysis as to what requirements are
placed on the boundaries between the different components of LISP (data
plane, control plane, mapping system, various extensions, etc.).  The
secdir reviewer had some good thoughts in this space.

The security considerations throughout the LISP documents place a heavy
focus on the risk of over-claiming for routing EID-prefixes.  This is a
real concern, to be clear, but it should not overshadow the risk of an
attacker who is able to move traffic around at will, strip security
protections, cause denial of service, alter data-plane payloads, etc.
Similarly, this document's security considerations call out denial of
service as a risk from Map-Cache insertion/spoofing, but the risks from an
attacker being able to read and modify the traffic, perhaps even without
detection, seems a much greater threat to me.

I am not convinced that this protocol meets the current IETF requirements
for the security properties of Standards-Track Protocols without at least
LISP-SEC as a mandatory-to-implement component, and possibly additional or
stronger requirements.  (I did not do a full analysis of the system in the
presence of those security mechanisms, since that is not what is being
presented for review.)

Having an EID that is associated to user-correlatable devices has severe
privacy considerations, but I could not find this mentioned anywhere in all
of the LISP documents I've read so far.

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

I apologize for the somewhat scattered nature of these comments; there are
a lot of them and I was focusing my time more on trying to understand the
broader system, and the intended security posture, so they did not get as
much clean-up as I would have liked.  (Most of my review was performed on the
-18, though I have tried to update to the -20 as relevant.)

The instance ID provides for organizational correlation, another privacy
exposure.

Is there anything different between an "EID-to-RLOC Map-Request" and just a
"Map-Request"?  (Same question for "Map-Reply", too.)

There's a lot of stuff that seems to work best if there is symmetric
bidirectional traffic, with inline signalling of map version and
reachability changes, though clearly everything is designed to also work
with asymmetric connectivity or unidirectional traffic.  It would be nice
to have a high-level summary in or near the introduction about what kinds
of behavior/performance differences are expected for bidirectional vs.
unidirectional traffic.

Section 2

That's not the 8174 boilerplate; it's more than just adding a cite to the
2119 boilerplate.

Section 3

nit: "An address family that pertains to the Data-Plane." is a sentence
fragment.

   Ingress Tunnel Router (ITR):   An ITR is a router that resides in a
      [...]
      mapping lookup in the destination address field.  Note that this
      destination RLOC MAY be an intermediate, proxy device that has
      better knowledge of the EID-to-RLOC mapping closer to the

This doesn't seem like a 2119 MAY is necessary, but rather a statement of
fact that may not be known to the encapsulating ITR.

      Specifically, when a service provider prepends a LISP header for
      Traffic Engineering purposes, the router that does this is also
      regarded as an ITR.  The outer RLOC the ISP ITR uses can be based
      on the outer destination address (the originating ITR's supplied
      RLOC) or the inner destination address (the originating host's
      supplied EID).

I'm confused here, perhaps in multiple ways.  Are there now *two* LISP
headers on the packet?  Is the "outer RLOC the ISP ITR uses" the source
RLOC or the destination RLOC?

   Negative Mapping Entry:   A negative mapping entry, also known as a
      negative cache entry, is an EID-to-RLOC entry where an EID-Prefix
      is advertised or stored with no RLOCs.  That is, the Locator-Set
      for the EID-to-RLOC entry is empty or has an encoded Locator count
      of 0.

Is "empty" a distinct representation from "locator count of zero"?

Perhaps something of an aside, but the check described for
Route-Returnability is a somewhat weak check, and in some cases could still
be spoofed.  (I don't expect this to surprise anyone, of course, but
perhaps some more qualifiers could be added to the text.)

Section 4

   An additional LISP header MAY be prepended to packets by a TE-ITR
   when re-routing of the path for a packet is desired.  A potential
   use-case for this would be an ISP router that needs to perform
   Traffic Engineering for packets flowing through its network.  In such
   a situation, termed "Recursive Tunneling", an ISP transit acts as an
   additional ITR, and the RLOC it uses for the new prepended header
   would be either a TE-ETR within the ISP (along an intra-ISP traffic
   engineered path) or a TE-ETR within another ISP (an inter-ISP traffic
   engineered path, where an agreement to build such a path exists).

"the RLOC it uses for the new prepnded header", again, this is as the
destination RLOC (vs. source RLOC)?

Section 4.1

   o  Map-Replies are sent on the underlying routing system topology
      using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol.

Just to check my understanding: is the "underlying routing system topology"
the same as the "underlay"?

Is step (3) just describing more of what step (2) says is "not described in
this example"?

Section 5.3

The word "nonce" is normally used for something used exactly once.
E.g., with some AEAD algorithms, if the same "nonce" input is used for
different encryptions, the entire security of the system is compromised.
It would be better to refer to this field with a different term, given
that "the same nonce can be used for a period of time when encapsulating to
the same ETR".  "Uniquifier" or "random value" might be reasonable choices.

Why is there no discussion of the Map-Version or Instance-ID fields
in this section?

When doing ETR/PETR decapsulation:

   o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in
      the case of IPv6) SHOULD be copied from the outer-header 'Time to
      Live' field, when the Time to Live value of the outer header is
      less than the Time to Live value of the inner header.  Failing to
      perform this check can cause the Time to Live of the inner header
      to increment across encapsulation/decapsulation cycles.  This
      check is also performed when doing initial encapsulation, when a
      packet comes to an ITR or PITR destined for a LISP site.

Er, what is "this check" that is also performed for initial encapsulation?
How are there multiple TTL values to compare?

   o  The inner-header 'Differentiated Services Code Point' (DSCP) field
      (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
      copied from the outer-header DSCP field ('Traffic Class' field, in
      the case of IPv6) to the inner-header.

nit: the first "inner-header" seems like an editing remnant?

Section 7.1

How is this stateless if it invovles knowledge about the routers between
the ITR and all possible ETRs (i.e., a set that could change over time)?

Section 8

This 32-bit vs 24-bit thing is pretty hokey for a standards-track
specification (yes, I know that LISP-DDT is not standards track at the
moment).

Section 9

   Alternatively, RLOC information MAY be gleaned from received tunneled

What is this an alternative to?  The list of four options above?

   packets or EID-to-RLOC Map-Request messages.  A "gleaned" Map-Cache
   entry, one learned from the source RLOC of a received encapsulated
   packet, is only stored and used for a few seconds, pending
   verification.  Verification is performed by sending a Map-Request to
   the source EID (the inner-header IP source address) of the received
   encapsulated packet.

The source EID is some random end system, right?  So this relys on some
magic in the ETR to detect that there's a Map-Request and reply directly
instead of passing it on to the EID that won't know what to do with it?

Talking about the "R-bit" of the Map-Reply" is detail from 6833bis and
might benefit from an explicit section reference to the other document.

Section 10

What is the "CE" of "CE-based ITRs"?  Presumably Customer Edge, but it
is not marked as well-known at
https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion is
probably in order.

Again, when we are talking about the internal structure of the Map-Reply, a
detailed section refernce to 6833bis is useful.

Modifying LSBs seems like a fine DoS attack vector for an on-path attacker.

   value of 1.  Locator-Status-Bits are associated with a Locator-Set
   per EID-Prefix.  Therefore, when a Locator becomes unreachable, the
   Locator-Status-Bit that corresponds to that Locator's position in the
   list returned by the last Map-Reply will be set to zero for that
   particular EID-Prefix

Doesn't this imply a stateful relationship between the ordering of
Map-Replys and data-plane traffic?

Section 10.1

   Note that "ITR" and "ETR" are relative terms here.  Both devices MUST
   be implementing both ITR and ETR functionality for the echo nonce
   mechanism to operate.

Perhaps they could be given actual names so as to disambiguate which steps
are performed with ITR vs. ETR role?

   The echo-nonce algorithm is bilateral.  That is, if one side sets the
   E-bit and the other side is not enabled for echo-noncing, then the
   echoing of the nonce does not occur and the requesting side may
   erroneously consider the Locator unreachable.  An ITR SHOULD only set
   the E-bit in an encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed by the E-bit in the RLOC-
   probe Map-Reply message.

Why is this even optional?  If it was mandatory to use, then there would
not be a question.  But at least clarify that the "this" that is conveyed
is whether the peer supports the echo-nonce algorithm.  (Also, subject to
downgrade.)

Section 13

   When a Locator record is removed from a Locator-Set, ITRs that have
   the mapping cached will not use the removed Locator because the xTRs
   will set the Locator-Status-Bit to 0.  So, even if the Locator is in
   the list, it will not be used.  For new mapping requests, the xTRs
   can set the Locator AFI to 0 (indicating an unspecified address), as
   well as setting the corresponding Locator-Status-Bit to 0.  This
   forces ITRs with old or new mappings to avoid using the removed
   Locator.

The behavior describe here seems like it would be better described as "when
a Locator is taken out of service" than "removed from a Locator-Set", since
if it is not in the set at all, it has no index, and no LSB or AFI to set.
Should actually depopulating it like this be forbidden?

I guess the Map Versioning is supposed to help with this, but we need to
nail down the semantics more and/or give a clearer reference to it.

Section 13.1

   An ITR, when it encapsulates packets to ETRs, can convey its own Map-
   Version Number.  This is known as the Source Map-Version Number.

Replacing "its own Map-Version Number" with something like "the Map-Version
numer for the LISP site of which it is a part".  Writing this causes me to
note that the semantics of the Map-Version are unclear, here -- what is it
scoped to?  An EID-Prefix?  An RLOC?  Oh, you say that in the next
paragraph (EID-Prefix).

   A Map-Version Number can be included in Map-Register messages as
   well.  This is a good way for the Map-Server to assure that all ETRs
   for a site registering to it will be synchronized according to Map-
   Version Number.

Huh?  I must be confused how this works.  (Also, wouldn't this be better in
the control plane document which covers Map-Register?)

Section 15

   o  When a tunnel-encapsulated packet is received by an ETR, the outer
      destination address may not be the address of the router.  This
      makes it challenging for the control plane to get packets from the
      hardware.  This may be mitigated by creating special Forwarding
      Information Base (FIB) entries for the EID-Prefixes of EIDs served
      by the ETR (those for which the router provides an RLOC
      translation).  These FIB entries are marked with a flag indicating
      that Control-Plane processing SHOULD be performed.

I assume this is just my lack of background showing, but I'm confused how
it makes sense to mark these for control-plane processing.  Isn't the
control plane much slower, and we're not putting all of the LISP data-plane
traffic onto the slow path?

Section 18

   o  Data-Plane gleaning for creating map-cache entries has been made
      optional.  If any ITR implementations depend or assume the remote
      ETR is gleaning should not do so.

nit: this is ungrammatical; "they should not" or "Any ITR implementations
that depend on or assume that" would fix it.

Section 19.1

Presumably IANA also updated the reference column to point to this
document?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 26 Sep 2018 23:53:02 -0400

Is there text we can add about the scoping that will change your discuss 
into a series of useful comments?
If so, Some indication of how you would like that phrased would help us 
address these.

If not, we seem to have a larger problem.
Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Sep 2018 14:06:13 -0700

Fixing the simple issues first. Clipping out the rest of the text.

> "Map-Request"?  (Same question for "Map-Reply", too.)

No. But Map-Requests are used for lookups in the mapping system as well as for probing RLOCs for reachability.

> nit: "An address family that pertains to the Data-Plane." is a sentence

Fixed.

> fact that may not be known to the encapsulating ITR.

Agree. Fixed.

> RLOC or the destination RLOC?

No, just one. When referring to “inner” and “outer”, we mean IP headers.

> Is "empty" a distinct representation from "locator count of zero”?

Yes. Added text to make that more clear.

> destination RLOC (vs. source RLOC)?

Fixed.

> the same as the "underlay”?

Yes.

> this example”?

I lost your reference. Is it to the previous bulleted set or the one starting with “Client host1 …”?

> How are there multiple TTL values to compare?

“This check” is outer-header-TTL is < the inner-header-TTL.

> nit: the first "inner-header" seems like an editing remnant?

Fixed. This text has changed so many times, it’s not a surprise it became confusing.

> the ITR and all possible ETRs (i.e., a set that could change over time)?

The ITR does not keep state about underlay routers between it and the ETR.

> specification (yes, I know that LISP-DDT is not standards track at the

It is actually useful to allow more instance-IDs but not waste extra bits in the encapsulation header.

> What is this an alternative to?  The list of four options above?

Doing a mapping system lookup to get an RLOC-set.

> instead of passing it on to the EID that won't know what to do with it?

Not following your description.

> might benefit from an explicit section reference to the other document.

Done.

> https://www.rfc-editor.org/materials/abbrev.expansion.txt so expansion is

It is defined in the xTR definition.

> are performed with ITR vs. ETR role?

They are. An ITR is an encapsulator. An ETR is a decapsulator. This is defined in the definition section. When the functions are co-located, they refer to an xTR, also in the definition section.
> is whether the peer supports the echo-nonce algorithm.  (Also, subject to

Because it has cost implications in a hardware implementation.

> that depend on or assume that" would fix it.

Fixed. Thanks.

> Presumably IANA also updated the reference column to point to this

Yes, from my perspective.

Thanks,
Dino

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 28 Sep 2018 17:03:40 -0500

Hi Joel,

> into a series of useful comments?

I had attempted to structure my Discuss points so that they would either be
useful comments as is, or rendered moot by a reduced scope.  I guess I can
try to clarify those below.  (To be clear, reducing the scope is only going
to move from "has potentially existentially bad problems" to "has
substantial issues that likely require reengineering to resolve".)

> If so, Some indication of how you would like that phrased would help us 

I think Ekr's ballot position on 6833bis has a good summary of the
architecture assumptions that the reduced scope allows us to make.
In order to have the document be able to plausibly make those claims, it
looks like we'd need to at least:
(1) update the Abstract/Introduction to clarify that the EID namespace is
    only defined within a single administrative domain.
(2) (optionally, if it makes sense) mention in the introduction that this
    administrative domain can include transport over other networks in the
    same way that a VPN would function[*], without requiring cooperation
    from or interaction with the other networks' administrators
(3) remove the "global" text from the EID-to-RLOC Database and Map-Cache
    definitions
(4) update the EID-Prefix definition to talk about the local site or
    administrative domain's "address allocation authority"
(5) Take a look at the EID definition to consider whether references to "on
    the public Internet" are still valid, and the text about assignment
    in a hierarchical manner should be revised for the new scope as well.
    Likewise for EID-internal structure that is "not visible to the global
    routing system"

(I stopped skimming and looking for problematic text around section 6)

[*] Ideally this would be done without using the term "VPN" itself, since
I'd like to get a movement going to restrict "VPN" to include
confidentiality (i.e., privacy) protection.  "virtual network" or "overlay
network" may or may not be good candidate replacement terms.

> If not, we seem to have a larger problem.

Well, we appear to have five ADs that are supporting making LISP-SEC a
normative reference and thus MTI; I don't know if that scale of change
meets your threshold for a "larger problem".

> > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/

(rendered moot by scope reduction)

> > consideration as mitigating the security concerns with the core documents.

The downgrade attacks will probably require some further analysis; LISP-SEC
would protect a lot of the header bits but I think there may be some other
data flows to be looked at.

> > whole (that is, for a global Internet-scale system) is not fit for purpose.

(rendered moot by scope reduction)

> > authentication checks as well, since bad Map-Reply data can allow all sorts

(not affected by scope reduction)

> > more prominently in the data-plane document as well.

(not affected by scope reduction)

> > only 24 usable bits of Instance ID.

(not affected by scope reduction)

> > synchronization within a site should be clearly called out, ideally in a

(not affected by scope reduction, since ETRs are affected and not just
Map-Servers)

> > secdir reviewer had some good thoughts in this space.

(not affected by scope reduction)

> > detection, seems a much greater threat to me.

(not affected by scope reduction)

> > presence of those security mechanisms, since that is not what is being

(noting that LISP-SEC needs to be MTI and analysis performed under the new
assumptions)

> > of the LISP documents I've read so far.

(not affected by scope reduction)

-Benjamin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Sep 2018 18:38:34 -0400

As co-chair, I would like to hear from the working group as to whether 
making LISP-SEC mandatory to Implement (not Mandatory to Use) for 
LISP6830bis and 6833bis implementations is
a) desirable
b) acceptable
c) undesirable but livable
d) unacceptable or worse.

Please, do not just pick a letter.  Include explanation of your opinion.
This is not a decision the ADs and Authors can make for the working group.

Yours,
Joel

-------- Forwarded Message --------
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: 
(with DISCUSS and COMMENT)
Date: Fri, 28 Sep 2018 17:03:40 -0500
From: Benjamin Kaduk <[email-masked]>
To: Joel M. Halpern <[email-masked]>
CC: The IESG <[email-masked]>, [email-masked], Luigi 
Iannone <[email-masked]>, [email-masked], [email-masked]

Hi Joel,

-Benjamin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Sep 2018 18:41:24 -0400

Thank you Benjamin.  This response helps me understand the situation.
I have sent a note to the WG about making LISP-SEC MTI.  That kind of 
change needs WG support.

Yours,
Joel

---

From: Fabio Maino <[email-masked]>
Date: Fri, 28 Sep 2018 15:44:32 -0700

> Thank you Benjamin.  This response helps me understand the situation.

I second that. The email was indeed very helpful, and I think we can use 
it (together with Eric's notes) as a guide to move forward.

Thanks,
Fabio

>>>> Please refer to 
>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Fabio Maino <[email-masked]>
Date: Fri, 28 Sep 2018 15:45:29 -0700

Thanks,
Fabio

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 28 Sep 2018 15:56:58 -0700

(a) Desirable, because more security is always more desirable.

But the choices don’t seem to be comparable. Is “Desirable” more important or more mandatory than “Acceptable”? 

I would like better clarification what I’m voting for if I choose “acceptable” instead of “desirable”.

Dino

> On Sep 28, 2018, at 3:38 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> As co-chair, I would like to hear from the working group as to whether making LISP-SEC mandatory to Implement (not Mandatory to Use) for LISP6830bis and 6833bis implementations is
> a) desirable
> b) acceptable
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)
> CC: The IESG <[email-masked]>, [email-masked], Luigi Iannone <[email-masked]>, [email-masked], [email-masked]
> 
> Hi Joel,
> 
> 
>> Is there text we can add about the scoping that will change your discuss into a series of useful comments?
> 
>> If so, Some indication of how you would like that phrased would help us address these.
>

---

From: Fabio Maino <[email-masked]>
Date: Fri, 28 Sep 2018 15:58:01 -0700

> LISP6830bis and 6833bis implementations is

I have always seen LISP-SEC as part of the LISP "core" set of documents, 
so I agree that it is desirable to make it mandatory to implement.

There are also quite a few comments from Benjamin and Eric's review, 
including to make more clear the scope of applicability, that would 
certainly benefit the RFCbis.

As an author of LISP-SEC I'm willing to help addressing the changes 
above in the documents under review (as well as in LISP-SEC).

Fabio

> Subject: Re: Benjamin Kaduk's Discuss on 
> draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)
> CC: The IESG <[email-masked]>, [email-masked], 
> Luigi Iannone <[email-masked]>, [email-masked], [email-masked]
>
> Hi Joel,
>
>
>> Is there text we can add about the scoping that will change your 
>> discuss into a series of useful comments?
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 28 Sep 2018 16:04:04 -0700

> As an author of LISP-SEC I'm willing to help addressing the changes above in the documents under review (as well as in LISP-SEC).

And I’m willing to help you as well.

Dino

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 28 Sep 2018 18:24:20 -0500

> No. But Map-Requests are used for lookups in the mapping system as well as for probing RLOCs for reachability.

Okay.  I don't know if "Probe Map-Request" and plain "Map-Request" would
help the reader or not (I did find myself wondering the original question
while reading, of course).

> No, just one. When referring to “inner” and “outer”, we mean IP headers.

Okay, so the ITR is picking an "outer RLOC" based on either the "outer
destination address" or the "inner destination address".  My original
reading is that the "outer RLOC" being picked is the same thing as the
"outer destination address", which prompted me to think I was confused.  Is
it actually the outer source address that's being selected?  It's sounding
like I'm just not sure what field in the outer header the phrase "outer RLOC"
is referring to.

> Yes. Added text to make that more clear.

Thanks!  (I thought I had found some text elsewhere, maybe not even in this
document, to support my thought that they were the same, so it's good to
know that they're not.)

> > the same as the "underlay”?

Okay.  I don't request any text change here; I'm sure most readers are more
used to these terms than I am.

> I lost your reference. Is it to the previous bulleted set or the one starting with “Client host1 …”?

The "Client host1" one.  Basically, I'm thinking that sending a Map-Request
(step 3) is a method of mapping the destination EID to an RLOC (step 2).
Well, assuming a useful Map-Reply eventually shows up, I suppose.

> “This check” is outer-header-TTL is < the inner-header-TTL.

Ah, I see now that "this check" is both in "Failing to perform this check"
and the start of the following sentence.  In the first sentence of the
bullet point, though, it reads like "do X, if condition".  The last
sentece is just saying "check condition" without an apparent "do X"
associated with it.  So maybe it's better to say something about "when
performing initial encapsulation, the ITR or PITR must ensure that the
outer TTL is less than the inner TTL".

> Fixed. This text has changed so many times, it’s not a surprise it became confusing.

Understandable!

> The ITR does not keep state about underlay routers between it and the ETR.

Ah, so this is basically a "computed once by the network administrator,
then used as a configuration parameter" thing.

> Doing a mapping system lookup to get an RLOC-set.

I'd suggest something like "Instead of using the Map-Cache or mapping
system, [...]", as I was very uncertain how "Alternatively" was intended to
be interpreted.

> Not following your description.

The xTR receives an encapsulated packet (i.e., a data-plane message), and
can use the outer/inner IP headers to get an RLOC/EID pair.  The EID of
this pair, in general, is some end system, not necessarily an ITR or
router at all.  The xTR is supposed to do verification by sending a
Map-Request to this source EID, some arbitrary end-user system.  This
Map-Request is presumably not actually going to get *delivered* to the
system identified by that EID, right?  So is it better to say "sending to
the ETR responsible for that EID"  or something like that?

> It is defined in the xTR definition.

Ah, sorry for missing it.

> They are. An ITR is an encapsulator. An ETR is a decapsulator. This is defined in the definition section. When the functions are co-located, they refer to an xTR, also in the definition section.

In the narrative, we say things like "[w]hen the ETR next sends a data
packet to the ITR".  On the face of it, this phrase is absurd -- by
definition, an ITR is sending a data packet to an ETR, not the other way
around.  I know that in this example both are xTRs, but I feel pretty
strongly that it does a disservice to the reader by attempting to use the
role from the initial exchange as an identifier, as opposed to using
a distinct identifier that does not come into conflict with a later role.

> Yes, from my perspective.

It could be useful to document that in the RFC, though I don't feel
particularly strongly about it.

Thanks,

Benjamin

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 28 Sep 2018 20:24:37 -0400

I gave several positive choices to allow folks with nuances to express 
it.  Some folks who are willing to have a chnage, will not call it 
desirable.  Some folks who desire a change are unhappy if I label the 
choice "acceptable".  SO I gave folks both choices.

The difference will help me unerstand the sentiment better.  Still of 
bunch of people say "desirable" that probably produces the same result 
as if bunch of people say "acceptable".

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 29 Sep 2018 09:46:32 -0700

New diff file enclosed for revisions to -21 of 6830bis.

> On Sep 28, 2018, at 4:24 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

We use the term RLOC-Probe Map-Requests in many places in the document.

> destination address" or the "inner destination address".  My original

The inner destination address is the EID. The EID is looked up in its local map-cache to get an RLOC-set. A RLOC is selected from the RLOC-set. The selected RLOC address is the destination address in the outer header.

> like I'm just not sure what field in the outer header the phrase "outer RLOC"

The outer source address is the ITR’s RLOC address since it is building the outer header.

> Well, assuming a useful Map-Reply eventually shows up, I suppose.

I think the text is clear. I still don’t know where and why you are confused.

> outer TTL is less than the inner TTL”.

Will change. I want to keep the text the way it is because I want to explain what would happen if a larger TTL is copied to the outer header.

Yes.

> system, [...]", as I was very uncertain how "Alternatively" was intended to

Changed.

> Map-Request to this source EID, some arbitrary end-user system.  This

No, it sends a Map-Request FOR the source EID. But the Map-Request goes to the mapping system (sent to a Map-Resolver).

> system identified by that EID, right?  So is it better to say "sending to

Right.

> the ETR responsible for that EID"  or something like that?

Right.

> definition, an ITR is sending a data packet to an ETR, not the other way

Yes, you are right. Shoudl include “when an ETR is an xTR, …”. I’ll change to make it more clear.

Thanks,
Dino