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

[Martin Duke via Datatracker <[e-mail]>]

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.