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

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 10 Sep 2018 17:20:11 +0200

Hi Brian, hi ART!

Given the reviewed document below still has a discuss-worthy issue with ECN decapsulation, I though I send a quick pointer to rfc6040 to the ART list for future reference!

Thanks for the review and discussion already! That's super helpful and I hope the sec AD (based on the SEC-ART review) will continue the privacy discussion!

Mirja

> Am 27.08.2018 um 16:35 schrieb Brian Trammell <[email-masked]>:
> 
> Reviewer: Brian Trammell
> Review result: Ready with Issues
> 
>> From a transport standpoint, this document is basically OK -- I suspect that
> there are probably more transport-relevant issues to consider on 6833bis, but I
> did not review it. Two issues with the dataplane:
> 
> (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.
> 
> (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.
> 
> nit: Section 7.1. para 7 should note that the ICMPv6 message sent is called
> Packet Too Big, not Unreachable/Frag Needed.
> 
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art