[lisp] Eric Rescorla's Discuss on draft-ietf-lisp-rfc6830bis-20: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla 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:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3126

See my DISCUSS on 6833bis for overall issues. This is just detailed issues
on 6830bis as I went through it.


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.


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.


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.


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.


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?


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

S 5.3.
>         header.
>
>      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

This should probably be a MUST because there are other protocols that
assume that TTLs get decremented.


S 7.1.
>      destination site.  The two fragments are reassembled at the
>      destination host into the single IP datagram that was originated by
>      the source host.  Note that reassembly can happen at the ETR if the
>      encapsulated packet was fragmented at or after the ITR.
>
>      This behavior MAY be performed by the ITR only when the source host

Nit: I think you want to say MUST be, assuming you mean that you can
perform it only if....


S 7.2.
>      2.  When an IPv6-encapsulated packet, or an IPv4-encapsulated packet
>          with the DF bit set to 1, exceeds what the core network can
>          deliver, one of the intermediate routers on the path will send an
>          ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/
>          Fragmentation-Needed to the ITR, respectively.  The ITR will
>          parse the ICMP message to determine which Locator is affected by

What if you are in an environment where ICMP is blocked?


S 9.
>         outside of the subset list if it determines that the subset list
>         is unreachable (unless RLOCs are set to a Priority of 255).  Some
>         sharing of control exists: the server-side determines the
>         destination RLOC list and load distribution while the client-side
>         has the option of using alternatives to this list if RLOCs in the
>         list are unreachable.

How would you obtain alternative RLOCs?


S 10.
>          also acting as an ITR and has traffic to return to the original
>          ITR site, it can use this status information to help select an
>          RLOC.
>
>      2.  When an ETR receives an encapsulated packet from an ITR, the
>          source RLOC from the outer header of the packet is likely up.

What does "is likely up" mean?