> I'd suggest inserting a new paragraph after paragraph 2 of section 5, > something like: > > > NEW: > > As LISP uses UDP encapsulation to carry traffic between ITRs and ETRs across > the Internet, implementors should be aware of the provisions of [RFC8085], > especially those given in section 3.1.11 on congestion control for UDP > tunneling.
Consider it added to Section 5 “LISP Encapsulation Details”, last paragraph. > >>>>>>> (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. >>>> >>>> Well RFC8061 does AEAD on the payload. All data *after* the LISP header. >>>> The encryption is a more integrated model than IPsec, so we can be more >>>> efficient by not using extra IP headers and extra control/key exchange >>>> protocols. >>> >>> Okay, that's all well and good. The LISP header itself isn't integrity >>> protected, though? >> >> It is not, unless the outer UDP checksum is used. Which we suggest to be 0 >> and when NATs make it non-zero, ETRs ignore it. > > Ah. Okay, so two things: > > (1) By "integrity protection" I mean "cryptographic integrity protection", in > the sense of "preventing on-path attackers or off-path spoofers from being > able to influence ITR/ETR state through crafted LISP headers to the detriment > of the traffic of others". Looking over 8061, it seems to only cover > confidentiality of the data-plane payload, which is extremely useful but not > sufficient to prevent these attacks. Well at this point in the generation of LISP, the only text I think to mitigate LISP header corruption is to indicate that a LISP ITR can use an outer IPsec header if protection of the UDP and LISP headers need protection. Or is that not a strong enough statement? > The attacks seem to be well enumerated in 6830bis, but the lack of a stated > mitigation beyond "be careful" seems to suggest that the mitigation is "don't > use LISP", which is of course less than desirable. I'm trying to understand > whether the deployment scenarios envisioned for LISP make these attacks less > likely (for instance, because the ITR/ETR path itself is generally > cryptographically protected with its own outer tunnel), or whether this is > something that this document (or a future companion to 8061) needs to worry > about. I think so because of 8061. > (2) Checksums provide what I'd call "corruption protection". On "setting the > outer UDP checksum to zero", please be aware that this may have undesirable > interactions with IPv6 headers; see also section 3.4 (Checksum Guidelines) of > 8085. If we don’t go IPsec route, we go with the checksum route. What do you think? Meaning, that if LISP header protection is desiriable, use UDP checksums. > Thanks, cheers, > > Brian Thanks for the commentary and discussion, Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
