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

[Warren Kumari <[e-mail]>]

On Wed, Feb 6, 2019 at 2:41 PM Dino Farinacci <[e-mail]> wrote:

>
> >
> > 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?
>

Which changed text? It wasn't (as far as I could see) in the diff which you
attacked earlier.
Also, in the diff there is still the "example" typo: "For exmple of such
attacks"



>
> >  > 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.
>

... and someone reading this document is supposed to know that how? The
purpose of publishing documents like this is to allow for interoperable
implementations - expecting implementers to have to examine other
implementations to learn how not to shoot themselves in the foot doesn't
help anyone.

>
> > > 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).
>

Ok, this seems seems like a good optimization (but does require that the
RLOC storage needs to be larger ) - why not suggest this in the document?
It would only take a sentence or two, and would make future implementations
more likely / resilient.

>
> > 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.
>
>
Again, something like "many implementations default to not advertising that
they are echo-nonce capable in Map-Replies and so RLOC-probing tends to be
used for RLOC reachability." would help - there is no harm in trying to
make things easier for your readers / future implementors.



> > > 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.
>
>
Ok. No worries.
W



> Dino
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf