Subject: [lisp] Martin Duke's Discuss on draft-ietf-lisp-rfc6830bis-32: (with DISCUSS and COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Fri, 03 Jul 2020 12:06:51 -0700

Martin Duke has entered the following ballot position for
draft-ietf-lisp-rfc6830bis-32: 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:
----------------------------------------------------------------------

Having read this document front to back for the first time, I found it quite
hard to figure out what can actually safely done over the public internet, and
what can be only be done in trusted environments. I realize that this is
probably because the no-internet provisions entered late in the game. If it
were my document, I might reorganize it to make the distinction more clear
(i.e. present the internet-safe dataplane spec and then have additional
sections about insecure add-ons). That said, at this stage in the game I'd be
happy to have a new section that clarified what is what. For example (assuming
I'm reading it correctly, which is my point)

NEW:
"
Section 4 and a half. Deployment on the Public Internet

Many of the mechanisms in this document are intended for deployment in
controlled, trusted environments, and are insecure for use over the public
internet. In particular, on the public internet xTRs:

* SHOULD set the N, L, E, and V bits in the LISP header (sec 5.3) to zero;

* SHOULD NOT use gleaning as a method for Route Locator Selection (Sec 9);

* SHOULD NOT use any data plane methods described in Section 10 for Routing
Locator Reachability, instead relying solely on control plane methods;

* SHOULD NOT use any data plane methods described in Section 13 to update the
EID-to-RLOC mapping, instead relying solely on control plane methods.

"

END

Perhaps my text is inaccurate, but something to that effect would be very
helpful.

Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits are
zero?

Sec 7.2 The stateful MTU design does not incorporate any security measures
against ICMP spoofing. At the very least, the ITR needs to make sure that some
fields in the outer IP and UDP headers are hard to guess, and that this
information is stored to verify that the ICMP message came from on-path. If
this is not possible, the design is not safe to use over IPv4.  If
hard-to-guess information is not available to be stored deeper in the packet,
then it is not safe over IPv6 either.

Sec 7.2 There is a fourth situation which can arise. If the ETR receives an
ICMP packet from an EID in its network. I have a couple of questions about what
should happen in this case:

- How is this communicated to the sender of the flow that triggered the
message? Is there an "outer" ICMP to the ITR, and "inner" ICMP to the source
EID, both, or neither?

- Is the ETR responsible for enforcing the MTU to that EID for subsequent flows?

Sec 9. I don't understand what this sentence means:
"The client-side ITR controls how traffic is returned and can alternate using
an outer-header source RLOC, which then can be added to the list the
server-side ETR uses to return traffic."

This would appear to be the inverse of the "Routing Locator Hashing" discussion
in Section 12, which provides a technique for switching destination RLOC. Is
this "alternation" of source RLOC mean to be done on hashed 5-tuple basis (i.e.
each flow uses only one source RLOC)?

If not, would this involve potentially sending packets for one flow on
different interfaces with different path characteristics, causing packet
reordering. Or perhaps you mean each packet is sent from the same interface
with a spoofed source RLOC, which creates interesting issues for ICMP returns
and the like.

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

Sec 5.3. In the DSCP discussion, please add an information reference to RFC
2983, which provides guidance for DSCP and tunneling. It is not quite as simple
as simply always copying DSCP to the outer packet.

Sec 9. I don't understand what this sentence means:

"The value of the 'Weight'  represents the relative weight of the total packets
that match the maping entry." (s/maping/mapping, obviously)

What is the "relative weight" of packets? Is this the number of packets, the
cumulative number of bytes, or something else?

Sec 16. "If  the attacker spoofs the source RLOC, it can mount a DoS attack by 
redirecting traffic to the spoofed victim's RLOC, potentially  overloading it."

This not the only problem. The attacker could also DoS by directing traffic to
an unreachable RLOC.

---

From: Albert Cabellos <[email-masked]>
Date: Fri, 31 Jul 2020 14:43:39 +0200

Hi,

 Thanks for your comments, we have updated the draft accordingly (-33):

Find below the specific changes and responses to your comments:

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

We have added -almost verbatim- this to the following new section (section
4.1):

4.1.  Deployment on the Public Internet
   Several of the mechanisms in this document are intended for
   deployment in controlled, trusted environments, and are insecure for
   use over the public Internet.  In particular, on the public internet
   xTRs:
   o  MUST set the N, L, E, and V bits in the LISP header (Section 5.1)
      to zero.
   o  MUST NOT use Locator-Status-Bits and echo-nonce, as described in
      Section 10 for Routing Locator Reachability.  Instead MUST rely
      solely on control-plane methods.
   o  MUST NOT use Gleaning or Locator-Status-Bits and Map-Versioning,
      as described in Section 13 to update the EID-to-RLOC Mappings.
      Instead relying solely on control-plane methods.

> Sec 5.3 What is in the Nonce/Map-Version field if both the N and V bits
are

There is no field then.

> then it is not safe over IPv6 either.

The source UDP port is random. We have therefore added the following
statement at the beginning of section 7.7:

   An ITR stateful solution to handle MTU issues is described as follows,

> should happen in this case:

In this case the EID is locally attached to the xTR. Therefore, the xTR has
a locally configured MTU to reach the EID. So what is written in the
section already covers this scenario.

> with a spoofed source RLOC, which creates interesting issues for ICMP
returns

No, flows are always sent to the same RLOC, per “Routing Locator Hashing”.
The section is describing a standard LISP load-balancing (same priority
weight 0), which means that flows will be load-balanced across the RLOCs.

Added the sentence “Guidelines for this can be found at <xref
target="RFC2983">”

> cumulative number of bytes, or something else?

Typo changed, thanks!

Relative weight among the defined weights (0.5, 0.25, 0,25).

> This not the only problem. The attacker could also DoS by directing
traffic to

Thanks, Albert.

>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp