hi Dino, all, > On 27 Aug 2018, at 23:29, Dino Farinacci <[email protected]> wrote: > >>> 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" >> sorry, ate an interrupt, sorry about that. >> >> ... "congestion controlled itself (i.e., carried by any IETF transport) need >> to be aware that the ITR is ultimately responsible for not causing undue >> congestion, for example, using a circuit breaker.” > > Well I hear you, but you know there is a lot of technology developed that > uses UDP tunneling. And in this case, it isn’t used like a traditional > transport whereby a node is originating traffic. In this case, a LISP router > is forwarding packets just like any other IP router forwarding IP packets.
Yep. 8085 is where the we put our best current practices for doing this sort of thing, so IMO it's important for implementors to be aware of the things it says relative to tunneling. >>> I am not sure what more we can say. There is an depth discussion about DSCP >>> fields and how to use ECN. Basically copies the inner values to the outer >>> header equiv values. >> >> Concretely, I'd add a pointer to RFC 8085, especially section 3.1.11. > > But I am not sure what supporting text we should put around the reference. > Please advise. 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. >>>>>> (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. 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. (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. Thanks, cheers, Brian
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
