> Kyle, Dino, > > I fill like this discussion is going sideways w.r.t. the original 6830bis > document. > > You started to discuss other documents and other solutions, which, while > certainly interesting and important, belong to other threads and documents.
Well I think the security guys want to make sure LISP, holistically, is secure. So we have to present solutions that may not be in the data-plane. I agree though we should focus on data-plane security since that is what Kyle is reviewing. > > IMHO here are the few points that need to be clarified: > >> On 28 Aug 2018, at 23:48, Kyle Rose <[email protected]> wrote: >> >> Hi, Dino. I have additional responses inline. >> >> > For the internet core (DFZ RIB) use-case, LISP proposes replacing BGP >> > sessions >> > and global eventually-consistent state sharing with a global control plane >> > and >> >> LISP *does not propse to eliminate BGP*, in fact it needs it so RLOC >> reachability across the network is available, or there would be no underlay >> for the LISP overlay. >> >> The whole point of LISP is to create a routing overlay for the EID address >> space, the RIB of which is managed by a global mapping system, not BGP >> sessions. If control plane traffic managed by BGP (or static routes, or >> whatever networks use once the DFZ RIB is limited to entities in the core) >> continues to flow, that is of small comfort to end users trying to get data >> over the data plane. >From the perspective of end users, BGP is being >> replaced routing of the traffic that matters to them. >> >> Maybe this is just splitting hairs: I certainly don't want to rathole on >> this point. > > @Kyle: can we consider this point closed? From my standpoint, it should be. > > [trimmed] > >> https://tools.ietf.org/html/draft-ietf-lisp-sec-15#ref-I-D.ietf-lisp-rfc6833bis >> >> > One area of concern, of which I have not been able to find discussion, is >> > that >> > of the implications of shared capacity for the control and data planes, >> > and how >> > this can allow a volumetric data plane attack to deny a router access to >> > the >> > global mapping system, slowly choking off service to uncached portions of >> > the >> >> Well yes, this happens with all our IETF protocols. It is a valid concern >> and there are many operational techniques in network infrastructure that >> *help* solve (but not eliminate) these problems. >> >> I would like to see a discussion of whether and how the nature and scale of >> this problem differs from that of the status quo. BGP sessions and RIB push >> have properties that are well-established from decades of experience: surely >> LISP does not have exactly the same properties. The security considerations >> should make clear, for instance, how a loss of control plane connectivity >> differs from the loss of a BGP session, and how this impacts visibility and >> behavior of the data plane. > > I am not sure I understand the point. Isn’t this covered by RFC7835? > Reference to that document isn’t sufficient? > If not, can you clarify further? And I am not sure this is relevant to the data-plane. > >> >> > I would also like clarification on what defines the separation between the >> > control plane and data plane, and whether authentication itself is used to >> >> A control-plane obtains information to store in a table. The data-plane uses >> that table. That is the definition in the simpliest form. >> >> I mean specific to LISP, not generically. For instance, does "LISP >> Control-Plane signaling" include only valid messages, or valid + inauthentic >> (and presumably dropped) messages? Traditional attack traffic (e.g., a DDoS >> attack against a website) is part of the same data plane as all legitimate >> end user traffic; is attack traffic directed at control plane endpoints >> considered part of the control plane, or is it a third category of traffic? >> If the latter, then what does an operator need to do to ensure that control >> plane is always available? > > IMHO, these questions should be asked for in the 6833bis thread. Don’t you > guys agree? Yes, agree. Dino > > Ciao > > L. > > > > > >> >> Kyle > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
