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

[Albert Cabellos <[e-mail]>]

Hi,

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

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


Find below the specific changes and responses to your comments:

On Fri, Jul 3, 2020 at 9:07 PM Martin Duke via Datatracker <[e-mail]>
wrote:
>
> 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.
>

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
> zero?
>

There is no field then.

>
> 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.
>

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,
this solution can only be used with IPv4-encapsulated packets:

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

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.

>
> - 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.

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.

>
>
>
> ----------------------------------------------------------------------
> 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.
>

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

>
> 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?
>

Typo changed, thanks!

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

>
> 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.
>
>

Thanks, Albert.


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