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

[Vasilenko Eduard <[e-mail]>]

Hi Jen,
See in-line
Ed/
> -----Original Message-----
> From: Jen Linkova [mailto:[e-mail]]
> Sent: 17 сентября 2020 г. 11:37
> To: Vasilenko Eduard <[e-mail]>
> Cc: [e-mail]
> Subject: Re: I-D Action: draft-ietf-6man-grand-02 - override flag for preferred
> address
> 
> On Wed, Sep 16, 2020 at 7:28 PM Vasilenko Eduard
> <[e-mail]> wrote:
> > If addresses is promoted to "Preferred", then DAD has passed.
> 
> We all know how "reliable" DAD is.
> AFAIR during Berlin IETF we got ~25% false negatives for DAD on the IETF WiFi.
[Ed: ] We have to assume that DAD work. Or else we need to scrape it.
Moreover, probability of unintentional duplicates is extremely small.
It is not just because 2^64, but additionally lost multicast.
> 
> >Then there is no way to shut up any host (from both duplicates).
> 
> Not sure what you mean...Could you please elaborate?
[Ed: ] Before DAD finish - it is possible to send negative NA and push at least one host out of this address.
> 
> > 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.
> 
> Let's not call it MITM unless the first host is malicious and intends to forward
> traffic back to the second host.
[Ed: ] I am developing security feature. I should assume that 1st or 2nd could be the Intruder.
> 
> > 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.
> 
> I believe you need to define 'the legitimate' first.
> The grand draft follows the approach of the Optimistic DAD RFC4429:
> the host which got the address first is the rightful owner. The newcomer should
> not cause any disruption.
[Ed: ] It is the wrong approach: 1st is not always right.
I have shown already the situation when Intruder would catch server in reload that would give him chances to impersonate valuable corporate Server with application that everybody use.
If we have duplicate addresses and both are trying to use it - both should be blocked.
It would not happen without Intruder, because DAD should shut up one.
> 
> > Override flag set does permit for router to understand that address has
> achieved Preferred status (not optimistic) - action could be taken now.
> 
> I feel like I need to read your draft first so we can establish some common
> ground for the discussion.
[Ed: ] It is very right comment - it is very weak point in all this discussion that I have initiated. I hope very soon.
> Has it been submitted and I missed it? If you could provide a link, it would be
> highly appreciated.
> 
> > In general, I do not respect this story about "first-come/first-serve" (I propose
> to block both).
> 
> So far I'm afraid we disagree on this topic.
> As an operator I have a strong preference on minimizing the disruption for the
> existing elements.
> When I'm adding a new element to the network and there is smth wrong with it
> (e.g. a duplicated address), I want the new element to malfunction, not smth
> else.
[Ed: ] But what if such "disruption" could not happen in normal operation (address collision followed by DAD fail has very low probability).
What if it is clear evidence that you have Intruder. Would you put Security on priority? not convenience for NOC.
Especially in the respect to MITM and leakage of information.
> 
> >
> > -----Original Message-----
> > From: Jen Linkova [mailto:[e-mail]]
> > Sent: 16 сентября 2020 г. 5:29
> > To: Vasilenko Eduard <[e-mail]>
> > Cc: [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]> 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
> 
> 
> 
> --
> SY, Jen Linkova aka Furry