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

[Dino Farinacci <[e-mail]>]

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

I was referring to the MTU text. We combined two discussion points at the same time. I was referring to the the size of the packet that the ITR needs to encapsulate and that L includes the size of the encapsulation headers.

Fixed the typo.

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

Tell me why this text does not satisfy your concern?

It’s at the end of section 9.

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

Because we have decided that many things like this be left for implementor creativity and experimentation.

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

I have added your text. See new diff enclosed.

Dino