Hi John, I am coming back on your DISCUSS points, please see inline.
FYI revision -14 has been submitted, and should solve you COMMENTS as well. > On 2 Jun 2022, at 23:35, John Scudder <[email protected]> wrote: > > Hi Luigi, > > Thanks for your reply. My comments are in line below. > >> On Jun 2, 2022, at 8:29 AM, Luigi Iannone <[email protected]> wrote: > ... >>> On 1 Jun 2022, at 21:53, John Scudder via Datatracker <[email protected]> >>> wrote: > ... >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> This spec makes liberal use of the approach of dropping any packet received >>> with an unloved Map-Version number, for example (but not limited to) >>> >>> 2. The packet arrives with a Dest Map-Version number newer (as >>> defined in Section 6) than the one stored in the EID-to-RLOC >>> Database. Since the ETR is authoritative on the mapping, meaning >>> that the Map-Version number of its mapping is the correct one, >>> this implies that someone is not behaving correctly with respect >>> to the specifications. In this case, the packet carries a >>> version number that is not valid and packet MUST be silently >>> dropped. >>> >>> Isn’t it the case that by definition the packet has arrived at a valid ETR >>> for >>> the mapping (since as the text says, “the ETR is authoritative”)? Isn’t the >>> map-version more in the nature of a hint than a critical-for-correctness >>> field? >>> What bad behavior is being protected against by silently dropping this >>> traffic, >>> that has arrived at a correct endpoint albeit with an incorrect hint? >> >> The packet did not necessarily arrive at the correct ETR. >> We can take for instance the scenario depicted in Section A.3, where you >> want to shutdown an RLOC. >> Map-Versioning allows to trigger Map-Requests to make sure everybody uses >> the lates mapping, which in the example in Section A.3 means not using an >> ETR anymore. If the ETR continues to accept traffic and the IRT ignore the >> messages hinting at updating the mapping this will create problems. > > I get that if the ITR ignores the hint it’s problematic, because after all > you want to dry out the ETR prior to shutting it down (or shutting down the > mapping). I’m not arguing that any of these cases is a *good* case, although > I have argued that there are corner cases you’ve neglected. Rather, I’m > advocating for the robustness principle — appropriately enough, there’s a > vigorous debate going on over on arch-d right now about whether the > robustness principle is a terrible idea or a good one. There are principled > arguments both ways. > > I don’t get why it will create problems for the ETR to continue to forward > traffic for as long as the mapping exists, though. Obviously, when the > mapping goes away, then it *can’t* forward the traffic. That’s a different > case from what the document talks about though. > >> We may want to consider “Do we really need to drop in each and every case?" >> May be not, but it is hard to define exactly when dropping is too much. > > I agree that thinking through the cases is hard and saying “just drop the > traffic” is easy, and probably safe. (Only “probably” because I haven’t > thought through whether there’s any way for an attacker to trick me into > throwing away packets I shouldn’t, thereby completing the attack for them.) > One of the tricky part of LISP is the data-plane/control-plane interaction. LISP data-plane may trigger control-plane events in various cases. This is one of the key discussion that was going on about “security” in LISP. The robustness principle has been applied in the sense that in general the specifications are quite conservative about data-lane-triggered control-plane events. Hence, for instance, the "silently” part. On flip side, as you state, we can still “silently forward the packet” if the ETR is an RLOC for the destination EID, which can be due to few possibilities: - a form of mis-configuration (ETR has not been updated for instance and actually we are trying to do a shutdown...) - Some ITR not behaving correctly - Implementation bugs Still in the optic of being conservative on the control plane side effect it is better to not trigger an SMR, but in order to help the NOC solve the issue would be good to have q log action, hence modifying the text as follows: The packet MUST be dropped and an appropriate log action SHOULD be taken. What do you think? >> Incidentally, the MUST was previously a SHOULD, but we were unable to give a >> good definition of when the packets should not be dropped. >> >>> >>> At various points in the document there's a kind of vague assertion that >>> incorrect map-versions could be an attack. While I don't deny that, the >>> assertion isn't supported or elaborated on anywhere that I saw, which is >>> worrying and also makes it less convincing. Shouldn't the Security >>> Considerations talk about this? >> >> The risk of attack is mentioned only twice in the document. > > OK. I apologize for overstating the pervasiveness. To be more specific about > places I found (by searching for “drop”) that are unconvincing/unspecific as > to the rationale, I see: > > "Such a case is not valid with respect to the > specifications." > > "someone is not behaving correctly with respect > to the specifications” > > "or (worse) > it might be some form of attack” > > "either someone has not > respected the Record TTL or it is a form of spoof/attack” > > To be candid, if these bits of editorializing hadn’t been in the document, I > might not have started thinking about the question of why you’re dropping the > traffic to begin with. Yep, text can be improved. > >> Yes, in a general way, because can be DDoS, spoofing, or amplification. >> These are discussed in RFC 7835. > > Are you referring to RFC 7835 Section 3.3? I did check that (and I mention it > a few lines down). Or is there some other relevant analysis in that RFC? > >> Security consideration has a whole paragraph about DDoS. >> I am unsure on what exactly you consider as missing. > > Consideration about the tradeoffs between collateral damage to legitimate > traffic, manageability of the system (how is the operator supposed to figure > out why their traffic is being silently discarded?), and protection against > attack. It’s a multidimensional space with costs and benefits on each > dimension. Fair enough. A paragraph about this can be added in the security section. > >>> I did also go have a look at the Security >>> Considerations in draft-ietf-lisp-rfc6833bis-31, which also didn't help me. >>> RFC >>> 7835 §3.3 does touch on this, suggesting that maybe an attacker could use a >>> spoofed Map-Version to trigger a DoS attack. But this, too, is an >>> unsatisfying >>> rationale, since as you take pains to point out, rate limiting of >>> Map-Requests >>> and such is required. >> >> Which allows not to flood the network but can itself be attacked. If a >> create a lot of false packets triggering Map-Requests trigger a lot of >> Map-Requests that will fill up the rate limit. This is just another form of >> DoS. > > Your point being that a naive shared-queue rate-limiter will allow attack > traffic to starve out legitimate Map-Requests? Fair enough, although it seems > likely that a modestly more sophisticated design would mitigate that risk. It really depends on the scale. Smarter rate limitation design do put the bar higher to achieve DDoS, but are not a complete protection if you scale out. > It would be fair to point out that by applying the mitigation as close to the > attack as possible, you let the rest of your system be kept simple — I just > want to explore the question of whether the cost of that simplicity is worth > the benefit. From the experience gathered so far the answer is yes, in light of the general conservative approach used so far. Could this evolve in the future? Certainly, if there will be clear quantifiable benefits. > >>> Furthermore, if triggering Map-Requests is the concern, >>> couldn't the packet still be delivered, without triggering a Map-Request? >> >> Yes, you disable Map-Versioning ;-) > > Sorry, I don’t follow your point. (Maybe it’s just a joke that evaded my > sense of humor, you don’t have to explain if it’s not relevant.) > >> More seriously, not every packet will cause sending a Map-Request because >> of the rate limitation. >> I do not see other implementable mechanisms to make a more fine grained >> decision. >> Or do you have something specific in mind? > > I thought it was clear but let me restate. I’ll use an example since the > first attempt wasn’t clear. > > - Suppose an ETR E gets packet P, which dest map-version N. > - Suppose N is “greater than” the current map-version at the ETR. > - According to the spec, E silently discards P. > - I’m wondering if E could forward P according to its local mapping. > - Note that E would not generate a SMR. > > Benefits: > + user traffic gets delivered. > > Drawbacks: > - lack of delivery can be a (very crude!) signal to the user that something > is wrong, so maybe the problem would be less likely to be fixed. > - ? Did the exchange with Dino clarify the scenario? > >>> When this was an Experimental protocol this kind of thing was probably less >>> crucial to justify and explain, but I would have expected the experiment to >>> produce results that could be fed into this document. At the moment, the >>> "drop >>> any packet that doesn't comply with expectations" design feels arbitrary and >>> potentially brittle. I would appreciate some discussion of this design >>> choice, >>> thanks in advance. >> >> We had long discussions about security in the bis documents with Ben Kaduk >> (former Security AD) and my impression was that is better to be a bit >> conservative. But I am not a security expert either. > > OK. > >> I am not sure the above explanation are sufficient. >> Revision -13 has only some fixes for the IESG telecast. >> We can certainly discuss more your concerns and better identify what is >> missing afterwards. > > Thanks. Discussion is what it’s all about. :-) In the end, if the WG has made > an informed decision that erring on the side of caution is better, given the > costs, I’m comfortable with that. I wasn’t confident, from reading the > document, that the costs had been considered, so that’s why we’re having this > discussion. > >> I will anyway issue a -14 revision to fix the comments below > Revision -14 has been submitted. Please have a read and let me know if it addresses your concerns. Thanks Ciao L. > Thanks, I’ll look forward to having a look at that. > > Regards, > > —John >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
