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

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 15 Sep 2020 12:55:52 +0000

Hi Jen,
I did believe that your draft has already passed last call, I was late. Hence, I did not make one important comment.
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.

It is the only thing in my draft that needs change on host. The rest of changes are related only to router.
I need that legitimate host to announce the presence.
I have a temptation to say that GRAND is just pre-request.
Currently, I have to propose to replace GRAND by 50% of cases.

Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 14 сентября 2020 г. 4:50
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-6man-grand-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

        Title           : Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers
        Author          : Jen Linkova
	Filename        : draft-ietf-6man-grand-02.txt
	Pages           : 19
	Date            : 2020-09-13

Abstract:
   Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the
   link-layer addresses of neighboring nodes as well as to discover and
   maintain reachability information.  This document updates RFC4861 to
   allow routers to proactively create a Neighbor Cache entry when a new
   IPv6 address is assigned to a node.  It also updates RFC4861 and
   recommends nodes to send unsolicited Neighbor Advertisements upon
   assigning a new IPv6 address.  The proposed change will minimize the
   delay and packet loss when a node initiate connections to off-link
   destination from a new IPv6 address.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-grand/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-grand-02
https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-grand-02

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jen Linkova <[email-masked]>
Date: Wed, 16 Sep 2020 12:28:58 +1000

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

> 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

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 16 Sep 2020 09:28:54 +0000

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:[email-masked]]
Sent: 16 сентября 2020 г. 5:29
To: Vasilenko Eduard <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Action: draft-ietf-6man-grand-02 - override flag for preferred address

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

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

--

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 16 Sep 2020 10:32:44 +0000

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:[email-masked]] On Behalf Of Vasilenko Eduard
Sent: 16 сентября 2020 г. 12:29
To: Jen Linkova <[email-masked]>
Cc: [email-masked]
Subject: RE: I-D Action: draft-ietf-6man-grand-02 - override flag for preferred address

Hi Jen,

Eduard

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

- [with GRAND] the same

--

---

From: Jen Linkova <[email-masked]>
Date: Thu, 17 Sep 2020 18:36:48 +1000

On Wed, Sep 16, 2020 at 7:28 PM Vasilenko Eduard
<[email-masked]> 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.

>Then there is no way to shut up any host (from both duplicates).

Not sure what you mean...Could you please elaborate?

> Very bad things would happen:

Let's not call it MITM unless the first host is malicious and intends
to forward traffic back to the second 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.
>
>
>

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.

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

> On Tue, Sep 15, 2020 at 10:55 PM Vasilenko Eduard <[email-masked]> wrote:
>

---

From: Jen Linkova <[email-masked]>
Date: Thu, 17 Sep 2020 18:54:07 +1000

> Hence, GRAND could not improve security by extremely gentle behavior on legal hosts (O=0).

The GRAND goal is NOT to increase security. Not at all. GRAND operates
in the existing ND landscape and threat model.
Whatever attack is possible with the current ND state machine, would
be possible with GRAND. I believe that GRAND does not introduce any
new security issues.

> As we discussed before: address collision on 2^64 space that would follow by DAD lost – is extremely low probability for legal hosts.

I've seen duplicated addresses way too many times.

>Moreover, it assumes that multicast was lost and ND does not operate properly – not good assumption.

It's a reality on the ground. Like it or not. Multicast, especially on
busy WiFi networks, is unreliable.

> You would not lose much setting O=1 for preferred - it is legal by ND architecture if address progressed to Preferred.

Let me explain my concern.
I have an operational issue: not a huge but rather annoying one. I'd
like to solve it with minimal disruption to existing mechanisms.
Whatever works now should work as before.
I'm not trying to drastically improve ND, make it more secure or
anything. I noticed an assumption in the state machine logic which is
not always true, and I'd like to fix it.

Now, you are suggesting a bit more disruptive way of doing things. It
looks to me that your suggestion is a part of a big and ambitious plan
to drastically change the ND logic - sorry, I'm guessing here as I've
not read your draft yet.

When I change smth - a network, a code or  a protocol - I prefer to
minimize the scope of the change and do not make changes of a
different nature in one attempt.
So my suggestion is: let's discuss GRAND in its context and then your
draft can propose updates to RFC4861 which may or may not override the
GRAND changes.

> Because else I have to propose Override GRAND

Looking forward to reading your draft.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 17 Sep 2020 09:03:19 +0000

Hi Jen,
See in-line
Ed/
> Sent: 17 сентября 2020 г. 11:37
[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.
> 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.
> 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.
> 
> 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.
> 
> 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.
> > 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.
> >
> > > 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] 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.
> >
> > >
> >
> > > 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.
> >
> > - [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.
> >
> >
> >
> > --
> >

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 17 Sep 2020 09:22:37 +0000

In-line

> Sent: 17 сентября 2020 г. 11:54
> The GRAND goal is NOT to increase security. Not at all. 
[Ed: ] I know
GRAND operates in the
> existing ND landscape and threat model.
[Ed: ] "Threat model" RFC is fully obsolete. It does not have discussion about MITM, not at all.
And it is not very useful to just reference to "Threat model" - it is not a good excuse. It is better to discuss the essence of particular problems.
> Whatever attack is possible with the current ND state machine, would be
> possible with GRAND. I believe that GRAND does not introduce any new security
> issues.
[Ed: ] In reality it does. I would show you in the draft. Intruder would intercept tens of ms more traffic with GRAND in some corner case (in the beginning after host inactivity).
But current MITM attack is so effective that it does not make sense to block GRAND or improve it in any way.
> 
> > As we discussed before: address collision on 2^64 space that would follow by
> DAD lost – is extremely low probability for legal hosts.
> 
[Ed: ] Ops, Please educate me why?
> It's a reality on the ground. Like it or not. Multicast, especially on busy WiFi
> networks, is unreliable.
[Ed: ] Then we need to redefine ND completely. Then my efforts to fix ND is useless.
We should not rely on something that everybody believe "does not work".
> 
> > You would not lose much setting O=1 for preferred - it is legal by ND
> architecture if address progressed to Preferred.
> 
> I have an operational issue: not a huge but rather annoying one. I'd like to solve
> it with minimal disruption to existing mechanisms.
> I'm not trying to drastically improve ND, make it more secure or anything. I
> noticed an assumption in the state machine logic which is not always true, and
> I'd like to fix it.
[Ed: ] It is perfectly logical position in the scope "just GRAND, other things are not in scope".
I am trespassing you tolerance pushing you to expand scope a little bit
(without big problem for GRAND or ND or any current practices)
> 
> Now, you are suggesting a bit more disruptive way of doing things. It looks to
> me that your suggestion is a part of a big and ambitious plan to drastically
> change the ND logic - sorry, I'm guessing here as I've not read your draft yet.
[Ed: ] I hope not drastically. Or else it would be rejected by market and this working group.
> 
> When I change smth - a network, a code or  a protocol - I prefer to minimize the
> scope of the change and do not make changes of a different nature in one
> attempt.
[Ed: ] I do understand that you would not do this till you would read my draft and understand justification.
You are right: you do not have any justification now, even for small thing that I am asking.
> So my suggestion is: let's discuss GRAND in its context and then your draft can
> propose updates to RFC4861 which may or may not override the GRAND
> changes.
[Ed: ] I would not vote against current GRAND.
Because if my proposal would be rejected - then you have the optimum now.
I do not know how to do GRAND better for the current (narrow) scope.
> > 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:
> >
> 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.
> >
> >
> >
> > 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.
> >