Subject: Re: [lisp] Reviewing the updated LISP docs

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Feb 2019 05:40:56 -0800

Now with LISP on the To: line

On Thu, Feb 7, 2019 at 5:37 AM Eric Rescorla <[email-masked]> wrote:

> I apologize for the length of this e-mail, but there's a lot to
> go over.
>
> I have gone over the responses to my DISCUSS on the LISP
> documents as well as taken another look at LISP-SEC. I agree that a number
> of the
> issues I raised are resolved, and I note those below. However,
> I believe that a number of issues remain.
>
> First, as a procedural I do not think it's appropriate to approve two
> documents (6830bis and 6833bis) which have critical security
> dependencies on documents (LISP-SEC, Map-Version) which are not yet
> before the IESG and therefore have contents which might change during
> IETF-LC. I'll happily re-review all these documents together.
> Alternately, you can precisely state the properties of LISP-SEC
> that you are depending on and we can review these documents
> assuming those are correct and then subsequently review
> LISP-SEC against that standard.
>
> Second, LISP-SEC is MTI, not MTU, but that means that we need
> to evaluate the security properties of LISP in the case where
> LISP-SEC is not in use; I do not believe those properties are
> appropriate for a new Internet protocol, as they do not provide
> reasonable security against integrity attacks. Is there a reason
> that comsec is not mandatory in this case? Note the text
> in RFC 3552 which says:
>
>    Note: In general, the IESG will not approve standards track protocols
>    which do not provide for strong authentication, either internal to
>    the protocol or through tight binding to a lower layer security
>    protocol.
>
> Additionally (and this is dicta because LISP-SEC is not before
> us), the design of LISP-SEC seems unnecessarily complicated and
> brittle, so at some point that's worth examining.
>
> Moving to the DISCUSS-worthy points I raised in my review (ignoring
> non-blocking comments for now).
>
>
> RFC 6833bis
> > THREAT MODEL
> > I'm assuming the usual RFC 3552 threat model, I.e.,
> >
> > - All non-Map Server elements in the system (specifically, endpoints
> >   and the xTRs are potentially malicious).
> >
> > - Aside from the links between the Map Server elements, the network
> >   is controlled by the attacker.
> >
> > Against this background, my expectation is that the attacker
> > should not be able to affect traffic in any fashion significantly
> > more effective than tampering with the data plane. For instance,
> > it's clearly the case that an on-path attacker between two xTRs
> > can drop all the packets or forward them to some third xTR, but
> > it should not be able to send a small number of packets which
> > would then affect the routing of a large number of packets.
> >
> > I do not expect that the data plane should have better security
> > than native (non-IPsec) traffic. Given the nature of LISP and
> > the existence of a mapping system, it seems like it's kind of
> > a missed opportunity to deploy a credentials system that would
> > support IPsec-style data plane security, but given that this
> > isn't a generally safe assumption for IP traffic, and therefore
> > you need to provide some sort of transport or application security
> > anyway, I don't think it's the right standard to hold LISP to.
>
> This is preface.
>
>
> > ATTACKS
> > LISP appears to be vulnerable to a number of routing attacks that
> > I claim above it should not be subject to. For example:
> >
> > 1. An on-path attacker can forge Map Replys to the ITR,
> >    thus redirecting traffic.
> >
> > 2. An ETR can perform an "overclaiming" attack in which it
> >    claims to be responsible for EIDs which it is not actually
> >    responsible for.
>
> I believe that both of these are intended to be protected against
> by LISP-SEC, but LISP-SEC is not MTU.
>
>
> > 3. An off-path attacker can temporarily reroute traffic by exploiting
> >    the "gleaning" feature to cache poison an ITR. In addition, the
> >    "echo noncing" feature does not appear to have a sufficiently strong
> >    nonce to protect against forgery, and thus turning this into a
> >    long-term attack
> >
> > 4. An attacker may be able to perform a number of cache invalidation
> >    and contamination attacks by exploiting the Map-Version and
> >    Locator-Status bits. This may lead to DoS.
>
> In the spreadsheet, you say that this is addressed in the 6833-bis
> security considerations, but I don't see it. In any case, I don't
> understand why it cannot be fixed, rather than just documented.
>
>
> > 5. An attacker who was at time T responsible for an EID block
> >    can probably prolong its ability to respond for that block
> >    even after it is no longer responsible.
>
> I agree that this is addressed.
>
>
> > 6. A number of the components appear to be subject to various replay
> >    attacks.
>
> As above, I don't believe that this is fixed.
>
>
> > DEFENSES
> > When looking at attacks, it's important to determine whether there are
> > plausible defenses. For most of these, I believe that the answer is
> > "yes", at varying levels of cost. As noted above, LISP-SEC appears to
> > be intended to address a number of these issues, so it's possible that
> > requiring LISP-SEC would go a fair ways towards addressing these
> > issues. A cursory look at LISP-SEC turns up some somewhat concerning
> > design choices, so I would have to examine it more closely to give a
> > real opinion.
> >
> > I do not believe that LISP-SEC will address the attacks that do not
> > involve the Mapping Server. For instance, the gleaning
> > contamination/nonce attacks (3) would not appear to be fixed by
> > LISP-SEC. However, it's probably possible to fix them by lengthening
> > the nonce.
>
> It's not clear to me that these are documented, but even if they
> are, they should be fixed or at least we need an explanation of
> why they can't be. The nonce one is especially obvious as it
> seems to be just a case of making it bigger. Relying on uBPRF
> does not seem sufficient.
>
>
> > With that said, I tend to think that the overall authentication
> > architecture here would benefit from a rethink. At a high level, the
> > source of most of these problems is the "non-transferability" of the
> > mapping information from the Map Server. If the Map Server instead had
> > an asymmetric key pair which it used to sign mappings, then almost all
> > of these attacks would not work. Specifically:
> >
> > - The map server could send signed Map Replys so forgery wouldn't work
> >
> > - Map Replys from ETRs would be signed, so you couldn't overclaim
> >
> > - Gleaning attacks would sort of work, but because the probe would
> >   elicit a Map Reply, you couldn't persist them
> >
> > - Map Versions could be tied to signed objects, so you couldn't do
> >   cache invalidation by version. You'd probably need some other
> >   approach for Locator Status bits.
> >
> > And so on.
>
> You say that there is text about this in security considerations,
> but it mostly seems to just restate the current design, not explain
> why a better one is not possible.
>
> > IMPORTANT
> > S 5.2.
> > >      s: This is the SMR-invoked bit.  This bit is set to 1 when an xTR
> is
> > >         sending a Map-Request in response to a received SMR-based Map-
> > >         Request.
> > >
> > >      m: This is the LISP mobile-node m-bit.  This bit is set by xTRs
> that
> > >         operate as a mobile node as defined in [I-D.ietf-lisp-mn].
> >
> > This would appear to create a normative reference to this document. To
> > avoid that, you need to specify how I behave if I receive it but I
> > don't implement lisp-mn.
>
> I agree that this is fixed.
>
>
> > S 5.2.
> > >      m: This is the LISP mobile-node m-bit.  This bit is set by xTRs
> that
> > >         operate as a mobile node as defined in [I-D.ietf-lisp-mn].
> > >
> > >      I: This is the xTR-ID bit.  When this bit is set, what is
> appended to
> > >         the Map-Request is a 128-bit xTR router-ID.  See LISP PubSub
> usage
> > >         procedures in [I-D.ietf-lisp-pubsub] for details.
> >
> > here too you seem to be creating a normative reference.
>
> This as well.
>
>
> > S 5.5.
> > >         is being mapped from a multicast destination EID.
> > >
> > >   5.5.  EID-to-RLOC UDP Map-Reply Message
> > >
> > >      A Map-Reply returns an EID-Prefix with a prefix length that is
> less
> > >      than or equal to the EID being requested.  The EID being
> requested is
> >
> > How do I behave if I receive an EID-Prefix that is less than any of my
> > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16
> > and someone asks me for 10.0.0.0/8? Also, when you talk about prefix
> > length, I assume you mean the length fo the mask?
>
> We had an extended back and forth on this. I still don't find the document
> very clear, and I'm not sure that this text is correct. Specifically,
> consider the following example, where the MS has two mappings:
>
>    10/8 -> ETR1
>    10.0.1/24 -> ETR2
>
> The Map-Request is for 10.1/16. In email, we agreed that you cannot return
> only the first mapping because that would implicitly over-claim. This means
> that you either supset one of your mappings or return both (I understood
> Dino to be saying you return both). However, the 10.0.1/24 mapping has
> a longer prefix than the requested one, so that would seem to violate this
> text.
>
>
> > S 5.6.
> > >      Authentication Data:  This is the message digest used from the
> output
> > >         of the MAC algorithm.  The entire Map-Register payload is
> > >         authenticated with this field preset to 0.  After the MAC is
> > >         computed, it is placed in this field.  Implementations of this
> > >         specification MUST include support for HMAC-SHA-1-96 [RFC2404],
> > >         and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED.
> >
> > What prevents replay attacks here? I'm guessing it's the Map-Version-
> > Number, but as I understand it, I can set this to 0.
>
> You write in your spreadsheet:
> "We have fixed this, now Map-Register have an incremental nonce to
> prevent replay attacks (in 6833bis: "Nonce: This 8-octet 'Nonce' field
> is incremented each time a Map-Register message is sent") "
>
> It's not clear to me why this prevents replay. Can you please walk me
> through the mechanism?
>
>
>
>
> > S 6.1.
> > >      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.  Since the mapping database system is a more secure way to
> > >      reach an authoritative ETR, it will deliver the Map-Request to the
> > >      authoritative source of the mapping data.
> >
> > If I'm understanding this correctly, this allows an ETR to prevent an
> > ITR from learning that it is no longer the appropriate ETR for a
> > prefix. The way this attack works is that before the topology shift, I
> > send SMRs, thus causing Map-Requests, which, because my entry is
> > cached, refresh the cache on the ITR past the topology shift. I can
> > keep doing this indefinitely. Am I missing something
>
> I agree with your response here and consider this resolved.
>
>
>
> > S 8.2.
> > >      authentication data, so prior to sending a Map-Register message,
> the
> > >      ETR and Map-Server SHOULD be configured with a shared secret or
> other
> > >      relevant authentication information.  A Map-Server's configuration
> > >      SHOULD also include a list of the EID-Prefixes for which each ETR
> is
> > >      authoritative.  Upon receipt of a Map-Register from an ETR, a Map-
> > >      Server accepts only EID-Prefixes that are configured for that ETR.
> >
> > How does it know?
>
> This now seems to be clear.
>
>
> > COMMENTS
> > S 5.
> > >        \ |           UDP Length          |        UDP
> Checksum           |
> > >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> |                                                               |
> > >          |                         LISP
> Message                          |
> > >
> |                                                               |
> > >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > What do these two diagrams correspond to? v4 and v6? This needs
> > explanation.
>
> This seems to be resolved.
>
>
> RFC 6830 bis
> > DETAIL
> > S 4.1.
> > >          RLOC (outer-header source IP address) in a received LISP
> packet.
> > >          Such a cache entry is termed a "glean mapping" and only
> contains
> > >          a single RLOC for the EID in question.  More complete
> information
> > >          about additional RLOCs SHOULD be verified by sending a LISP
> Map-
> > >          Request for that EID.  Both the ITR and the ETR MAY also
> > >          influence the decision the other makes in selecting an RLOC.
> >
> > This seems like it introduces an immediate overclaiming problem.
>
> I seem to have misunderstood this.
>
>
> > S 10.
> > >      When an ETR decapsulates a packet, it will check for any change in
> > >      the 'Locator-Status-Bits' field.  When a bit goes from 1 to 0, the
> > >      ETR, if acting also as an ITR, will refrain from encapsulating
> > >      packets to an RLOC that is indicated as down.  It will only resume
> > >      using that RLOC if the corresponding Locator-Status-Bit returns
> to a
> > >      value of 1.  Locator-Status-Bits are associated with a Locator-Set
> >
> > This seems to enable a pretty obvious denial of service attack in
> > which you send  a message with all LSBs set to 0.
>
> The change here seems to be:
>
> " An ETR MUST rate-limit the action it takes when it detects changes in
> the
>   Locator-Status-Bits."
>
> I'm not sure I understand what this text means, but in any case it
> doesn't seem to address the concern I had, which was the use of
> LSB=0 to empty the cache. It's not clear why rate limiting helps
> that.
>
>
>
> > S 10.
> > >      list returned by the last Map-Reply will be set to zero for that
> > >      particular EID-Prefix.  Refer to Section 16 for security related
> > >      issues regarding Locator-Status-Bits.
> > >
> > >      When an ETR decapsulates a packet, it knows that it is reachable
> from
> > >      the encapsulating ITR because that is how the packet arrived.  In
> >
> > It doesn't even know this. It just knows that that's been claimed by
> > someone who can generate traffic to it.
>
> This was mostly about clarity.
>
>
> > S 10.1.
> > >      NOT use the lack of return traffic as an indication that the ETR
> is
> > >      unreachable.  Instead, it MUST use an alternate mechanism to
> > >      determine reachability.
> > >
> > >   10.1.  Echo Nonce Algorithm
> > >
> >
> > This mechanism seems sufficient to verify unreachability but is not a
> > secure test of reachability because the nonce is way too short.
>
> Your response (as above) is that you updated security considerations,
> to document this, but why not simply fix it?
>
>
> > S 16.
> > >      Map-Versioning is a Data-Plane mechanism used to signal a peering
> xTR
> > >      that a local EID-to-RLOC mapping has been updated, so that the
> > >      peering xTR uses LISP Control-Plane signaling message to retrieve
> a
> > >      fresh mapping.  This can be used by an attacker to forge the map-
> > >      versioning field of a LISP encapsulated header and force an
> excessive
> > >      amount of signaling between xTRs that may overload them.
> >
> > Can't I also set a super-high version number, thus gagging updates?
>
> You say "This attack is discussed in the Security Section of 6830bis."
>
> The relevant text says:
>
>    Map-Versioning is a Data-Plane mechanism used to signal a peering xTR
>    that a local EID-to-RLOC mapping has been updated, so that the
>    peering xTR uses LISP Control-Plane signaling message to retrieve a
>    fresh mapping.  This can be used by an attacker to forge the map-
>    versioning field of a LISP encapsulated header and force an excessive
>    amount of signaling between xTRs that may overload them.
>
> A thorough analysis of this depends on Map-Versioning, which, as above,
> is not in scope here, but why can't this be fixed?
>
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 7 Feb 2019 16:14:49 -0800

Eric, just want to be clear on this one point. See below.

> > >      A Map-Reply returns an EID-Prefix with a prefix length that is less
> > >      than or equal to the EID being requested.  The EID being requested is
> > 

With the above entries in the mapping system, a Map-Request fro 10.1.0.0/16 gets returned the 10.0.0.0/8 entry.

(1) A Map-Request for 10.0.1.1/32 returns only 10.0.1.0/24.
(2) A Map-Request for 10.2.2.2/32 returns both 10.0.0.0/8 and 10.0.1.0/24 (even though 10.2.2.2 is not more specific than 10.0.1.0/24).
(3) A Map-Request for 10.0.0.0/<8 (less than 8) returns an empty RLOC-set.

As I mentioned last night if a Map-Request matches an entry in the mapping system and the mapping system has more specifics for that matched prefix, then all more specifics are returned. The reason is for when 10.0.1.1/32 is looked up in the ITR/RTR map-cache the /24 ETR2 is used.

The mapping system does not know what the ITR has cached so it must return all more specifics. I hope this clears things up.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 8 Feb 2019 12:02:48 +0100

Hi Eric,

just a quick comment on one point.

> On 7 Feb 2019, at 14:40, Eric Rescorla <[email-masked]> wrote:
> 
> On Thu, Feb 7, 2019 at 5:37 AM Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> documents as well as taken another look at LISP-SEC. I agree that a number of the
> IETF-LC.

We felt that would be better to hold those two documents back. On the one hand, to double check that they are coherent to any change introduced in the main specs (6830bis and 6833bis), before sending them further. On the other hand, we wanted (may be wrongly) avoid to swamp the IESG with LISP documents all at once.

Even looking at the decision now, I thing it was reasonable.

But let’s move forward…

LISP-SEC is under WG LC. 

Map-Versioning is on my to do lisp for a final check. I asked the shepherd (Padma) to hold on few more days before submitting the writeup and ask formally for publication.

All of this to say that soon you will have more reading ;-)

Ciao

L.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 8 Feb 2019 11:06:33 -0800

On Fri, Feb 8, 2019 at 3:02 AM Luigi Iannone <[email-masked]> wrote:

> We felt that would be better to hold those two documents back. On the one
> hand, to double check that they are coherent to any change introduced in
> the main specs (6830bis and 6833bis), before sending them further. On the
> other hand, we wanted (may be wrongly) avoid to swamp the IESG with LISP
> documents all at once.
>
> Map-Versioning is on my to do lisp for a final check. I asked the shepherd
> (Padma) to hold on few more days before submitting the writeup and ask
> formally for publication.
>

Thanks.

-Ekr