On Tue, Mar 13, 2018 at 12:28 PM, Alberto Rodriguez Natal (natal)
> 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
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
> 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  for a recent example. Regarding LISP in particular,
> you can find some research on the modeling of the LISP map-cache in .
> 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!
> "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  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 .
> 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
> Thanks again for your comments Tom. This is an interesting discussion :)
>  https://arxiv.org/pdf/1611.04825.pdf
>  https://arxiv.org/pdf/1312.1378.pdf
lisp mailing list