On Tue, Mar 13, 2018 at 12:28 PM, Alberto Rodriguez Natal (natal) <[email protected]> wrote: > Hi Tom, > > Apologies for the delayed response. Thanks for your time reading the draft > and for the feedback. See some comments inline. > > On 3/5/18, 4:42 PM, "Tom Herbert" <[email protected]> wrote: > > 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. > > As you point below, we're not saying otherwise in the draft. Sending the > traffic to an ILA-R while the mapping is being retrieved is certainly an > option. We'll update the text to be clearer on this. > > 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). > > IMHO, these should not be hard requirements. Leveraging ILA-Rs for mapping > resolution has another set of tradeoffs to be considered. An operator should > be able to decide which set of tradeoffs makes sense for his/her particular > scenario. > This is a hard requirement because caches are explicitly not required for ILA to operate. They are *only* optimizations. If there is a cache hit then packets presumably get optimized path, on a cache miss they might take a subopitimal route-- but packets still flow without being blocked! This means that the worse case DOS attack on the cache might cause suboptimal routing; however, if resolution is required then the worse attack case becomes that packets don't flow and it's a much more effective attack.
> 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. > > Heavy hitters counters are a well-known technique to mitigate DOS attacks in > the data-plane (used not only in LISP). There are several papers on that in > the literature, see [1] for a recent example. Regarding LISP in particular, > you can find some research on the modeling of the LISP map-cache in [2][3]. > Following that work, we did some designs on how to apply heavy hitters > counters to the LISP map-cache back in the day. We'll try to make that > research also available. As they say, the devil is in the details... :-) > > 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. > > That model is supported in LISP via the use of Map-Notifies. However, moving > the mapping resolution to the ILA-R comes at a cost. It's putting more load > (in terms of both data and control plane) into an architectural component > that it's not easy to scale out, since it requires (for instance) > reconfiguring the underlay topology. I'm not see how this creates more load (i.e. the need for map request packets are eliminated), but I really don't understand what "reconfiguring the underlay topology" means! Tom > > "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, ...? > > LISP can run as it is over TCP. It can also be extended with the mechanisms > described in [4] when a reliable transport is in place. If TCP makes more > sense for your particular scenario, then you can make it your preferred > transport. In general, which transport to use will depend on the > characteristics of each individual deployment. On you last point, please note > that OpenDaylight already supports LISP over REST [5]. > > 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? > > One thing that we can (and should) discuss is the best way to encode ILA > Identifier/Locators into LISP messages. Regarding removing fields from the > Map-Reply, I'm unsure that the cost of reducing protocol functionality, > increasing signaling machinery and adding parsing complexity is worth saving > a few bits. Specially if you are planning to later use an RPC version of the > protocol. > > Thanks again for your comments Tom. This is an interesting discussion :) > > Best, > Alberto > > [1] https://arxiv.org/pdf/1611.04825.pdf > [2] https://arxiv.org/pdf/1312.1378.pdf > [3] > http://personals.ac.upc.edu/fcoras/publications/2015-fcoras-scalability.pdf > [4] > https://tools.ietf.org/html/draft-kouvelas-lisp-map-server-reliable-transport-04 > [5] > https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Architecture > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
