RE: I-D Action: draft-ietf-6man-grand-02 - override flag for preferred address

[Vasilenko Eduard <[e-mail]>]

1 additional comment:
Intruder would not obey ND rules – he would set Override flag (and probably Solicited too).
Hence, GRAND could not improve security by extremely gentle behavior on legal hosts (O=0).
As we discussed before: address collision on 2^64 space that would follow by DAD lost – is extremely low probability for legal hosts. Moreover, it assumes that multicast was lost and ND does not operate properly – not good assumption.
You would not lose much setting O=1 for preferred - it is legal by ND architecture if address progressed to Preferred.

Because else I have to propose Override GRAND
That is not optimal standardization behavior (even if my draft would be rejected).
MITM is very important topic.

Ed/
From: ipv6 [mailto:[e-mail]] On Behalf Of Vasilenko Eduard
Sent: 16 сентября 2020 г. 12:29
To: Jen Linkova <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D Action: draft-ietf-6man-grand-02 - override flag for preferred address


Hi Jen,

If addresses is promoted to "Preferred", then DAD has passed. Then there is no way to shut up any host (from both duplicates). Very bad things would happen:

Only one would win the fight for neighbor cache record on the router.

1-way MITM: other one would sent upstream normal, but return traffic would go to first host.

2-way MITM at the same time: You could not assume what host (first or second) is more valuable - second one could be the important server after reboot. Then other one would get all requests to applications (DB, File Server, Web) from outside of the subnet. At least to collect passwords, and may be much more... depends on application type.



My problem: router could not see duplicity (and help) if at least legal host would not be persuasive to claim neighbor cache entry on the router.

Override flag set does permit for router to understand that address has achieved Preferred status (not optimistic) - action could be taken now.



In general, I do not respect this story about "first-come/first-serve" (I propose to block both). I have this text in my draft:

It could be the temptation to minimize Intercepted Victim disruption by blocking only the second node (first-come/first-serve approach). The Intruder would be the second in the majority of cases that would minimize disruption for Intercepted Victim. Unfortunately, there are less probable cases when Intruder would be capable to catch server with popular application in reload or upgrade state - than legal node would be blocked. The Intruder would be capable to pretend to be the particular application and start collection of valuable information from users that would visit this application. It would be at least login credentials and could be much more depending on application type. It is the leakage of information again. The leakage of information is considered much high security problem then DoS, hence such conversion of DoS back into leakage is not acceptable. Vulnerability harm is more important than the probability of vulnerability. It is especially true for [ND] where we have other DoS vulnerabilities anyway.

Only cryptographically based authentication does permit to really minimize DoS disruption for legal node.

Eduard

-----Original Message-----
From: Jen Linkova [mailto:[e-mail]]
Sent: 16 сентября 2020 г. 5:29
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: I-D Action: draft-ietf-6man-grand-02 - override flag for preferred address



On Tue, Sep 15, 2020 at 10:55 PM Vasilenko Eduard <[e-mail]<mailto:[e-mail]>> wrote:

> I did believe that your draft has already passed last call, I was late. Hence, I did not make one important comment.



That's perfectly fine - as the IESG asked for both drafts (v6ops-nd-cache-init and 6man-grand) to be merged, there will be another WGLC for 6man-grand.



> Meanwhile, I was working on my draft how to block MITM in ND. I am very unhappy about the leakage of information - you probably remember.

> I have almost finished - MITM blocked except very corner cases of host-to-host communication (no routers).

> But after many discussions with co-author we have found 1 hole that has been patched in this way:

>

> * Section 7.2.6 (Sending unsolicited NA) of [ND], add at the end:

> A node SHOULD send Neighbor Advertisement message with Override flag set to the all-routers multicast address after respective address would change state to preferred.

>

> There is the section later that explains interoperability with all ND-related extensions. Interoperability to GRAND is explained in this way:

> [Gratuitous ND] operates as intended in the combination with [Optimistic DAD].

> [Gratuitous ND] is effectively replaced by this document for the case when address is progressed to preferred, because stronger form of unsolicited NA (with override bit set) is proposed.

>

> May be I am asking too much (you better know IETF practices).

> 1. Could you consider to set Override flag after address progressed to Preferred? I need SHOULD.

> 2. Could you consider to recommend to send at least 1 unsolicited NA after address would go to preferred? I need SHOULD.



Setting O=1 would drastically increase the risk of disruption for a 'rightful' address owner, in case of duplicated addresses.

If a host configures a new preferred address while the same address is in use by another host:

- [without GRAND] the rightful owner continues to receive its traffic (and, potentially, some packets which actually belong to the new host). The new host does not have connectivity.

- [with GRAND] the same

- [ GRAND + O=1] the rightful owner losing the connectivity, and the new host starts receiving traffic for its own flows and some traffic which belongs to the rightful address owner.



--

SY, Jen Linkova aka Furry