Hi Dino, all, Sent from my iPhone On 27 Aug 2018, at 19:36, Dino Farinacci <farinacci@xxxxxxxxx> wrote: >> (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. Page 16, “UDP tunnels”. > Rather than make references, can you say what you think the issue is? LISP’s data plane is a UDP tunnel, and as such there are congestion control issues that must be considered. LISP inplementors and deployers using LISP to carry a mix of traffic that is not predominantly >> (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. I haven’t read 8061 yet, but I probably should before continuing this thread. I will say that I’m far less concerned about LISP header confidentiality than I am about LISP header integrity, given the opportunities for on-path meddling and off-path spoofing. If the common solution to both is something like sticking everything on the ITR-ETR path in IPSec then this is less of a concern. > >> 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. Yeah, this is the one place where i noticed a rough edge on supporting v4 and v6. Thanks. Cheers, Brian > Dino > > > _______________________________________________ > Tsv-art mailing list > Tsv-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tsv-art
