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