>> 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. > >> 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. > >>> >>>>> (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. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
