On Tue, Mar 13, 2018 at 12:28 PM, Alberto Rodriguez Natal (natal)
<na...@cisco.com> 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" <t...@quantonium.net> 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
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to