>
> 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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
