Re: [lisp] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15

[Dino Farinacci <[e-mail]>]

> (1) Common advice to all UDP-using encapsulation designers and implementors:
> please read RFC8085, especially section 3.1.11. As LISP's dataplane is
> basically an application of UDP, I was surprised to see no reference to RFC8085
> here. I believe that in the most common case LISP falls into case 1 here, but
> implementors of LISP ITRs should at least be made aware of the other cases.

I don’t see a section 3.1.11 in RFC 8085. Rather than make references, can you say what you think the issue is?

> (2) This is not transport-specific. Reading the document, it struck me that the
> design of the protocol has a few inherently unsafe features related to the fact
> that its wire image is neither confidentiality- nor integrity-protected. I
> think that all of the potential DDoS and traffic focusing attacks I could come
> up with in the hour I spent reviewing the document are indeed mentioned in the
> security considerations section, but as the security considerations section
> does not give any practical mitigation for dataplane overload attacks, it seems
> to be saying that RLOC addresses shouldn't be Internet-accessible, which as I
> understand it is not the point of LISP. I haven't seen a secdir review on this
> document yet, but I'd encourage the authors to do everything it asks.

RFC 8061 goes along with RFC6830bis. It addresses data-plane confidentiality.

> nit: Section 7.1. para 7 should note that the ICMPv6 message sent is called
> Packet Too Big, not Unreachable/Frag Needed.

We used “Packet Too Big” for all ICMP messages including IPv4 and hence we received comments about it on how it should change it to Network Unreachable. I will fix this for IPv6.

Dino