Re: [lisp] Warren Kumari's Discuss on draft-ietf-lisp-rfc6830bis-26: (with DISCUSS and COMMENT)

[Dino Farinacci <[e-mail]>]

> 
> What happens if you send 10,000,000 BGP routes in an update and the receiver can’t store it. It is the same problem. We have lots of research on this problem and there are pointers in the spec to it.
> 
> Well, what happens is that I tear down the session:
> accepted-prefix-limit {
>       maximum {{ peer_prefix_limit }};
>       teardown 85 idle-timeout 10;
> }
> 
> This is somewhat of a false analogy - I only accept BGP routes from configured peers, not just anyone on the Internet. 
> A better analogy would be Neighbor Discovery, where a random person on the Internet can cause your router to have to build state -- and we ended up having to publish RFC6583 - "Operational Neighbor Discovery Problems" to address exactly this issue.

I don’t think it is. Because a BGP table and a cache is still allocable memory that has to be managed. And it doesn’t matter if peers are configured or not, a bad peer can still damage a BGP cache.

And those limits can be placed on the LISP table as well.

> L is an architectural constant. If there tends to be tunnels between the ITR and ETR, then you choose L to be 1400. Or you run MTU discovery between the ITR and ETR to determine the effective MTU.
> 
> That doesn't sound like an "architectural constant" - it sounds like a configurable value.
> As an example: 
> "Both OSPF and IS-IS make a clear distinction between architectural constants and configurable parameters. Architectural constants are parameters which were fixed by the specification and cannot be changed by the network manager". 
> (from "OSPF and IS-IS: From Link State Routing Principles to Technologies").
> See also https://tools.ietf.org/html/rfc2328#appendix-B , https://tools.ietf.org/html/rfc3719, etc. 

Was the changed text sufficient?

>  > 4: "Note that reassembly can happen at the ETR if the encapsulated packet was
> > fragmented at or after the ITR." - I think that there needs to be more text /
> > description about resource constraints on routers performing reassembly of
> > fragments - in most cases a router doesn't have to / isn't expected to have to
> > reassemble transit packets from arbitrary sources on the Internet (things where
> > routers may reassemble are aimed at the control plane which can be
> > rate-limited, or are from expected source addresses). It seems that spoofing
> > lots of initial fragments without the final one will be a tax on the router.
> 
> We have chosen 3 methods to deal with MTU issues because ETR reassembly is the worst approach. And I certainly wouldn’t recommend using it.
> 
> Fair, but I think the document should say so. 

I don’t think it should. If someone has ETR resources to do so, it should be able to do it. Fragmentation/assembly is in the protocol to be used. Is it a good idea, that’s another question. Is it practical, that is another question.

> > deprecated. I start a timer, and second or two less than the TTL later I start
> > spoofing packets again, knowing that site X will soon expire the cache entry
> > and will once again be willing to accept mine again. A: I get some Site X to
> > Site Y traffic for a few seconds every TTL seconds, and B: the loss of this
> > traffic is a signal that TTL seconds again it will need to be refreshed.
> 
> It was a Google employee in the early days that wanted this feature (circa 2007). ;-) It was so return packets from a server side didn’t have to do the mapping system lookup. It is off by default and only used in trusted enviornments where you can control how the ITR and ETR behave.
> 
> You say that "it is off by default" -- but I don't see that in this document (nor, at a quick glance, in RFC 7832 - "Locator/ID Separation Protocol (LISP) Threat Analysis”).

It has been implemented in products as off by default.

> > valid nonce the ITR is requesting to be echoed within a small window of time. 
> > The goal is to convince the ITR that the ETR’s RLOC is  reachable even when it
> > may not be reachable."  attack listed in the document in that a: it doesn't
> > require any guessing, and b: makes an ETR appear down, not up.
> 
> You can’t overfill any cache. An xTR just remembers the last nonce that came with the E-bit set and when it returns packets it uses that nonce.
> 
> Um, I don't think this is right (or I've misunderstood) - you don't store "the last nonce that came with the E-bit set" (one number), you have to store "the last nonce that came with the E-bit set for every ITR which is sending them”.

Right. The context was from a single encapsulator.

> These have to be stored somewhere, and this is a limited size space (N slots). If I send you N+1 spoofed packets you will have to evict something from this space -- what am I missing?

They are stored in the map-cache since you encap to that ITR (which is now an ETR). So its a 24-bit number you use in an RLOC data structure in your implemenation. I have implemented this way twice (in 2 different implementations).

> Yes, many implementations default to not setting advertising they are echo-nonce capable in Map-Replies. So RLOC-probing tends to be used for RLOC reachability. Plus we added features into RLOC-probing that makes it more useful now (lisp-crypto key exchange for one).
> 
> 
> Pointer?

The LISP WG can provide pointes. Damien and Luigi did extensive research on this.

> > The document does mention "... attack can be mitigated by preventing RLOC
> > spoofing in the network by deploying uRPF BCP 38 [RFC2827]." - while that may
> > be true for many of the above, BCP38 is far from being universally deployed,
> > and this feels similar to solving world hunger by saying everyone must have
> > enough food. :-)
> 
> An ETR can verify mappings if it chooses to. The more overhead you want to put in the system for anti-spoofing, one can do. Tradeoffs.
> 
> By the way food is everywhere, you just have to be willing to eat it.  ;-)
> 
> As someone who was born in Africa and has seen the effects of famine firsthand, I find this statement offensive -- people don't starve to death because they didn't feel like eating their broccoli, they starve to death because there isn't any food.

It wasn’t intended to be offensive. And if that is how it was received, I am sorry for that.

Dino