Thanks for posting the draft! Overall, I think the approach straightforward, and it's very nice that there is no change required to the ILA architecture.
I have some concerns about the LISP control plane in terms of DOSability and scalability. Btw, LISP is not in Linux kernel because of concerns about DOSability, so there was some prior discussion on this topic in related mailing lists, >From the draft: "When an ILA-N has to send traffic towards a remote Identifier for which it does not have the associated Locator, it has to obtain it first from a MS." This is not actually true. The forwarding cache in the ILA-N is a routing optimization, if there is no entry on the cache then the packet is forwarded. If it needs to be transformed then that will be done by an ILA-R in the path. Until the cache is populated the routing might be sub-optimal but packets still flow. This is reflected below in: "While the mapping is being resolved via the Map-Request/ Map-Reply process, the ILA-N can send the data packets to the underlay using the SIR address." I think it should be assumed in ILA that not queuing packets and not dropping packets because of resolution are requirements (too much latency hit). If the map request is sent and the packet is forwarded, that means that a packet received at the ILA-N can generate two packets to be forwarded in the network. An obvious DOS attack is for a host to send random to destinations in the network to try to generate cache misses. Section 8.2 discusses this, but the solution to implement heavy hitters counters is not detailed. It would be nice to see more detail how this would work and how it will mitigate the DOS attack. In ILAMP, a redirect method is defined. On a chache miss the packet is forwarded and no other action is taken. If an ILA-R does transformation it may send back a mapping redirect informing the ILA-N of a transformation. The redirects must be completely secure (one reason I'm partial to TCP) and are only sent to inform an ILA-N about a positive response. To a large extent this neutralizes the above random address DOS attack. There are other means of attack on the cache, but the exposure is narrowed I believe. "LISP as defined in [I-D.ietf-lisp-rfc6833bis] runs over a UDP transport, however the exact same signaling can be used over a TCP transport without affecting the protocol operation." What is the status of TCP support? I believe the trend in datacenter control protocols is towards TCP and even RPC. Integrated security, congestion control, authentication, and tooling are strong points in favor of TCP. Is it reasonable to say that TCP is the preferred protocol? Can the LISP message easily be converted to RPC (REST, Thrift, GRPC, ...? Looking at the map-reply message format, I am concerned about its size. By my count, it's 40 bytes to provide one record with one locator where record and locator are 8 bytes. If we need to scale a system to billions of nodes this overhead could be an issue even if it's the control plane. Is there any plan to have a compressed version of this. For instance ,if there is only one RLOC returned wouldn't the priorities and weights be useless? Thanks, Tom On Sat, Mar 3, 2018 at 10:39 PM, Alberto Rodriguez Natal (natal) <[email protected]> wrote: > Hi all, > > > > We have just posted a draft describing how to use the LISP control-plane > with the ILA data-plane. The document is in an early stage and any feedback > is welcome. We hope to be presenting this at London. > > > > https://tools.ietf.org/html/draft-rodrigueznatal-ila-lisp-00 > > > > Thanks, > > Alberto > > > _______________________________________________ > ila mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ila > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
