Re: [lisp] Reviewing the updated LISP docs

[Eric Rescorla <[e-mail]>]

Now with LISP on the To: line

On Thu, Feb 7, 2019 at 5:37 AM Eric Rescorla <[e-mail]> 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?
>
>
>