Re: [lisp] John Scudder's Discuss on draft-ietf-lisp-6834bis-12: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

Hi Luigi,

Thanks for your reply. My comments are in line below.

> On Jun 2, 2022, at 8:29 AM, Luigi Iannone <[e-mail]> wrote:
...
>> On 1 Jun 2022, at 21:53, John Scudder via Datatracker <[e-mail]> 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.)

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

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

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

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

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

Thanks, I’ll look forward to having a look at that.

Regards,

—John