Subject: Re: [**EXTERNAL**] RE: New draft-vasilenko-6man-nd-mitm-protection - trust model

From: "Mudric, Dusan" <[email-masked]>
Date: Tue, 17 Nov 2020 15:54:21 +0000

Hi Eduard,

Is the algorithm saying that NS should be multicasted from hosts, during address resolution, and if a host should check if there are multiple responses? What is the host supposed to do when the attack is discovered? How the attacker can be identified and blocked?

is the algorithm protecting against DAD attacks?

Thanks,
Dusan

On 2020-11-17, 10:28 AM, "ipv6 on behalf of Vasilenko Eduard" <[email-masked] on behalf of [email-masked]> wrote:

Hi Philip,
It is not possible to force Intruder to do anything. Intruder could send unicast NS with any possible flag set. He is intruder - definitely out of any IETF restrictions.
You have misunderstood proposal.

Intruder is trying to poison cache on the router. Rewrite (or initial write) of MAC should happen on the router.
Hence, router should sent multicast NS to give chance for victim to reply, then router would see duplicity.

By the way, in the absence of GRAND, Router would send multicast NS anyway (after traffic would return from the Internet).
Additional functionality is just count how many NA responses would be received.

Hence, your excepts from ND and IP addressing RFCs are not relevant - I do not propose to change anything in the way how NS/NA should be done.
I propose to just count number of NAs after multicast NS.
And additionally (in GRAND environment) to generate multicast NS (where before was possible to check reachability by unicast NS).

Eduard
> -----Original Message-----
> From: [email-masked] [mailto:pch-b9D3CB0F5@u-
> 1.phicoh.com] On Behalf Of Philip Homburg
> Sent: 17 ноября 2020 г. 18:09
> To: [email-masked]
> Cc: Vasilenko Eduard <[email-masked]>
> Subject: Re: New draft-vasilenko-6man-nd-mitm-protection - trust model
> 
> > Then it is not
> > the way how security is done. Security is "the many layers that
> > Intruder should penetrate".
> 
> I don't like this approach at all. ND is fundamental to IPv6. We should be very
> careful making changes to ND. Making changes that break things ("Link Layer
> Address rewrite or initial write for any Neighbor Cache entry MUST be the result
> of only *multicast* Neighbor Solicitation.") need very strong justification. In my
> opinion the marginal effect this draft has on security is not worth it.
> 
> However, upon reflection there also seems to be a fundamental flaw in how this
> draft works.
> 
> The key idea of this draft is the following:
> "Link Layer Address rewrite or initial write for any Neighbor "Cache entry MUST
> be the result of only *multicast* Neighbor "Solicitation. Multicast would give a
> chance for Poisoned Victim "to understand that many nodes are going to use the
> same IP "address.
> 
> So an attacker A wants to update the neighbor cache entry for victim V on
> router R with MAC address of the atacker MAC_A.
> 
> Today the attacker can send a point-to-point NS with source V and destination R
> and source link-layer address option with value MAC_A.
> 
> The proposal is to force the attacker to send a multicast NS. Then, the idea is
> that the victim will also see this multicast and can generate an alert.
> 
> This is what RFC 4861 (ND) says about multicast:
> "the solicited-node multicast address corresponding to the target address"
> (Section 4.3).
> 
> This multicast address is defined in RFC 4291 (IP Version 6 Addressing
> Architecture) as:
> "Solicited-Node multicast address are computed as a function of a "node's
> unicast and anycast addresses.  A Solicited-Node multicast "address is formed by
> taking the low-order 24 bits of an address "(unicast or anycast) and appending
> those bits to the prefix
> "FF02:0:0:0:0:1:FF00::/104
> (Section 2.7.1)
> 
> Section 7.2.1. of RFC 4861 has this:
> "When a multicast-capable interface becomes enabled, the node MUST "join the
> all-nodes multicast address on that interface, as well as "the solicited-node
> multicast address corresponding to each of the IP "addresses assigned to the
> interface.
> 
> So the victim host does not listen to the solicited-node multicast address of the
> NS, because that packet goes to the router. So the victim will never know, unless
> the victim does not do multicast filtering (and neither does the network).
> 
> This proposal also requires interesting layering violations to implement
> correctly, but I'll leave that for another discussion.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!OSsGDw!blQRTv4BqQkFOeKBoJDQq5j3MA7FeNpCZnNBY3CboPhC1m0ebd8aMRUlvIET$ 
--------------------------------------------------------------------

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 17 Nov 2020 16:06:09 +0000

Hi Dusan,
We do not propose any DoS mitigation. Only MITM protection (prevent leakage of information).

By this draft we propose the same algorithm for both: host and routers (count NAs after multicast NS).
Host to host communication typically needs one multicast NS, second host would get stale record that could be checked by unicast NS.
Here is deficiency of this draft that second host should do multicast NS too.
It is important to get the protection of routers 1st - primary communication is to default router.
Hence, despite universal rules, We hope that routers would be protected first.
If it would happen that ND would be never patched on hosts - it is the small problem.
But yes, it is needed to count NA responses on hosts for host to host communication.

All of these are stated in the draft.

Eduard
> From: Mudric, Dusan [mailto:[email-masked]]
> Sent: 17 ноября 2020 г. 18:54
> To: Vasilenko Eduard <[email-masked]>; Philip Homburg <pch-
> [email-masked]>; [email-masked]
> Subject: Re: [**EXTERNAL**] RE: New draft-vasilenko-6man-nd-mitm-
> protection - trust model
> 
> Hi Eduard,
> 
> Is the algorithm saying that NS should be multicasted from hosts, during address
> resolution, and if a host should check if there are multiple responses? What is
> the host supposed to do when the attack is discovered? How the attacker can be
> identified and blocked?
> 
> On 2020-11-17, 10:28 AM, "ipv6 on behalf of Vasilenko Eduard" <ipv6-
> [email-masked] on behalf of [email-masked]> wrote:
> 
> Hi Philip,
> It is not possible to force Intruder to do anything. Intruder could send unicast NS
> with any possible flag set. He is intruder - definitely out of any IETF restrictions.
> By the way, in the absence of GRAND, Router would send multicast NS anyway
> (after traffic would return from the Internet).
> Hence, your excepts from ND and IP addressing RFCs are not relevant - I do not
> propose to change anything in the way how NS/NA should be done.
> And additionally (in GRAND environment) to generate multicast NS (where
> before was possible to check reachability by unicast NS).
> 
> Eduard
> > I don't like this approach at all. ND is fundamental to IPv6. We
> > should be very careful making changes to ND. Making changes that break
> > things ("Link Layer Address rewrite or initial write for any Neighbor
> > Cache entry MUST be the result of only *multicast* Neighbor
> > Solicitation.") need very strong justification. In my opinion the marginal effect
> this draft has on security is not worth it.
> >
> > However, upon reflection there also seems to be a fundamental flaw in
> > how this draft works.
> >
> > "Link Layer Address rewrite or initial write for any Neighbor "Cache
> > entry MUST be the result of only *multicast* Neighbor "Solicitation.
> > Multicast would give a chance for Poisoned Victim "to understand that
> > many nodes are going to use the same IP "address.
> >
> > So an attacker A wants to update the neighbor cache entry for victim V
> > on router R with MAC address of the atacker MAC_A.
> >
> > Today the attacker can send a point-to-point NS with source V and
> > destination R and source link-layer address option with value MAC_A.
> >
> > The proposal is to force the attacker to send a multicast NS. Then,
> > the idea is that the victim will also see this multicast and can generate an alert.
> >
> > "Solicited-Node multicast address are computed as a function of a
> > "node's unicast and anycast addresses.  A Solicited-Node multicast
> > "address is formed by taking the low-order 24 bits of an address
> > "(unicast or anycast) and appending those bits to the prefix
> > "When a multicast-capable interface becomes enabled, the node MUST
> > "join the all-nodes multicast address on that interface, as well as
> > "the solicited-node multicast address corresponding to each of the IP
> > "addresses assigned to the interface.
> >
> > So the victim host does not listen to the solicited-node multicast
> > address of the NS, because that packet goes to the router. So the
> > victim will never know, unless the victim does not do multicast filtering (and
> neither does the network).
> >
> > This proposal also requires interesting layering violations to
> > implement correctly, but I'll leave that for another discussion.
> 
> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!O
> SsGDw!blQRTv4BqQkFOeKBoJDQq5j3MA7FeNpCZnNBY3CboPhC1m0ebd8aMRUl
> vIET$

---

From: "Mudric, Dusan" <[email-masked]>
Date: Tue, 17 Nov 2020 16:19:12 +0000

Hi Eduard,

The draft is not clear. 

What is a host (or a router) supposed to do when it detects two responses to a multicasted NS, during address resolution? 

Section 4, Security DAD, 
"Multicast would give a chance for Poisoned Victim
      to understand that many nodes are going to use the same IP
      address."
Address collision is very rare. Most of the time the attacker would be the only one responding to multicated NS for DAD detection. What is the host supposed to do after this attack?

Thanks,
Dusan.

On 2020-11-17, 11:06 AM, "Vasilenko Eduard" <[email-masked]> wrote:

Hi Dusan,

Eduard

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 17 Nov 2020 18:39:54 +0000

Hi Dusan,
The logic is encoded in the section 4.1.1.
If more responses then configured "DuplicityLevel" (that is decremented on every NA received),
Then block this IP address:
" If DUPLICITY counter is 0: Change Neighbor Cache entry to DUPLICATE state. Clear all packets in the queue related to this target address. Log duplicate address event with target address and both Link Layer addresses (from received NA and from cache entry). Start DuplicateTimer for this Neighbor Cache entry. "
But it is exactly the point that discussable: what to do in this situation?

All of this is not related to address collision, because during DAD nobody (except Intruder) would respond by NA that he does use this IP address. MAC re-write would not happen - nothing to react.
If DAD would fail it's duty - it is not acceptable problem that needs ND redesign. Hence, we could assume that DAD works.
Eduard
> Sent: 17 ноября 2020 г. 19:19
> What is a host (or a router) supposed to do when it detects two responses to a
> multicasted NS, during address resolution?
> 
> Section 4, Security DAD,
> Address collision is very rare. Most of the time the attacker would be the only
> one responding to multicated NS for DAD detection. What is the host supposed
> to do after this attack?
> 
> Thanks,
> Dusan.
> 
> Host to host communication typically needs one multicast NS, second host
> would get stale record that could be checked by unicast NS.
> > To: Vasilenko Eduard <[email-masked]>; Philip Homburg
> > <pch- [email-masked]>; [email-masked]
> > Is the algorithm saying that NS should be multicasted from hosts,
> > during address resolution, and if a host should check if there are
> > multiple responses? What is the host supposed to do when the attack is
> > discovered? How the attacker can be identified and blocked?
> >
> > It is not possible to force Intruder to do anything. Intruder could
> > send unicast NS with any possible flag set. He is intruder - definitely out of any
> IETF restrictions.
> > Intruder is trying to poison cache on the router. Rewrite (or initial
> > write) of MAC should happen on the router.
> > By the way, in the absence of GRAND, Router would send multicast NS
> > anyway (after traffic would return from the Internet).
> > Hence, your excepts from ND and IP addressing RFCs are not relevant -
> > I do not propose to change anything in the way how NS/NA should be done.
> > And additionally (in GRAND environment) to generate multicast NS
> > (where before was possible to check reachability by unicast NS).
> >
> > Eduard
> > > should be very careful making changes to ND. Making changes that
> > > break things ("Link Layer Address rewrite or initial write for any
> > > Neighbor Cache entry MUST be the result of only *multicast* Neighbor
> > > However, upon reflection there also seems to be a fundamental flaw
> > > in how this draft works.
> > >
> > > Multicast would give a chance for Poisoned Victim "to understand
> > > that many nodes are going to use the same IP "address.
> > >
> > > So an attacker A wants to update the neighbor cache entry for victim
> > > V on router R with MAC address of the atacker MAC_A.
> > >
> > > "the solicited-node multicast address corresponding to each of the
> > > IP "addresses assigned to the interface.
> > >

---

From: "Mudric, Dusan" <[email-masked]>
Date: Tue, 17 Nov 2020 22:24:57 +0000

Hi Eduard,

" during DAD nobody (except Intruder) would respond by NA that he does use this IP address"
GUA is pseudo random. It is possible to generate GUA that already exists on link.

If DuplicityLevel=1 and after NS there is one NA, how does the host know it is NOT an attack? One NA response can still be an attack.

I still don't see how DAD attack is detected.

Regards,
Dusan.

On 2020-11-17, 1:40 PM, "Vasilenko Eduard" <[email-masked]> wrote:

Hi Dusan,

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 18 Nov 2020 17:07:05 +0000

> Sent: 18 ноября 2020 г. 1:25
[Ed: ] Fully possible. Especially if IID would be cut to 8bits (the flame is going in parallel - already 500 messages).
But node in DAD stage would not answer by NA,
And node would not rise any flag (even with GRAND) at the time of DAD.
MAC write or rewrite would not happen (no override bit set) - the mechanism proposed in this draft would not be activated.

Then DAD would help to resolve the collision.
> 
> If DuplicityLevel=1 and after NS there is one NA, how does the host know it is
> NOT an attack? One NA response can still be an attack.
[Ed: ] If only one NA to multicast NS - then no any attack, nothing to block.
Collision would be resolved by DAD. No one legal host would answer with flags set during DAD timer.
> I still don't see how DAD attack is detected.
[Ed: ] I hope it clear now.
> If more responses then configured "DuplicityLevel" (that is decremented on
> every NA received), Then block this IP address:
> " If DUPLICITY counter is 0: Change Neighbor Cache entry to DUPLICATE state.
> Clear all packets in the queue related to this target address. Log duplicate
> address event with target address and both Link Layer addresses (from received
> NA and from cache entry). Start DuplicateTimer for this Neighbor Cache entry. "
> All of this is not related to address collision, because during DAD nobody (except
> Intruder) would respond by NA that he does use this IP address. MAC re-write
> would not happen - nothing to react.
> > What is a host (or a router) supposed to do when it detects two
> > responses to a multicasted NS, during address resolution?
> >
> > Section 4, Security DAD,
> > Address collision is very rare. Most of the time the attacker would be
> > the only one responding to multicated NS for DAD detection. What is
> > the host supposed to do after this attack?
> >
> > Thanks,
> > Dusan.
> >
> > On 2020-11-17, 11:06 AM, "Vasilenko Eduard"
> > <[email-masked]>
> > wrote:
> >
> > Hi Dusan,
> > Host to host communication typically needs one multicast NS, second
> > host would get stale record that could be checked by unicast NS.
> > > multiple responses? What is the host supposed to do when the attack
> > > is discovered? How the attacker can be identified and blocked?
> > >
> > > Additional functionality is just count how many NA responses would
> > > be
> > received.
> > >
> > > Hence, your excepts from ND and IP addressing RFCs are not relevant
> > > - I do not propose to change anything in the way how NS/NA should be
> done.
> > > > "Link Layer Address rewrite or initial write for any Neighbor
> > > > "Cache entry MUST be the result of only *multicast* Neighbor
> "Solicitation.
> > > > So an attacker A wants to update the neighbor cache entry for
> > > > victim V on router R with MAC address of the atacker MAC_A.
> > > >
> > > > The proposal is to force the attacker to send a multicast NS.
> > > > Then, the idea is that the victim will also see this multicast and
> > > > can generate an
> > alert.
> > > >
> > > > "join the all-nodes multicast address on that interface, as well
> > > > as "the solicited-node multicast address corresponding to each of
> > > > the IP "addresses assigned to the interface.
> > > >
> > > IETF IPv6 working group mailing list [email-masked] Administrative
> > > Requests:
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ip
> > > v6
> > > __;!!O
> >

---

From: "Mudric, Dusan" <[email-masked]>
Date: Wed, 18 Nov 2020 22:11:39 +0000

Hi Eduard,

Neither in presentation nor in draft, I did not get how the solution works. Is there a step by step process to detect DAD attacks?

" But node in DAD stage would not answer by NA,"
You mean a host doing DAD is not answering with NA or a host with the same address is not answering with NA?

"And node would not rise any flag (even with GRAND) at the time of DAD."
Which node, which flag?

"MAC write or rewrite would not happen (no override bit set) - the mechanism proposed in this draft would not be activated."
I guess this means normal DAD would not start new algorithm (which I could not get from the draft)?

" Then DAD would help to resolve the collision."
You mean current DAD will resolve the collision buy assigning a new address?

"[Ed: ] I hope it clear now."
I suppose we agree on the current DAD, but I have no idea what the new algorithm does. Can you please add a section in the draft explaining the main DAD attack detection ideas?

Thanks,
Dusan.

---

From: "Mudric, Dusan" <[email-masked]>
Date: Wed, 18 Nov 2020 22:11:39 +0000

Hi Eduard,

Thanks,
Dusan.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 19 Nov 2020 15:37:57 +0000

Hi Dusan,

Let's assume that 1st legal host is working fine.
Second legal host in DAD status (checking) would not try to override cache on any router.
Hence, The algorithm from my draft would not try to block anybody.
I did not discuss it in the draft because there is no problem. It is potentially possible to add.

Optimistic DAD:
* (modifies section 5.4.3) The node MUST reply to a Neighbor
        Solicitation for an Optimistic Address from a unicast address,
        but the reply MUST have the Override flag cleared (O=0).

GRAND:
If the address is in the Optimistic state then the Override flag MUST NOT be set.

Eduard
> Sent: 19 ноября 2020 г. 1:12
> To: Vasilenko Eduard <[email-masked]>; [email-masked]
> Neither in presentation nor in draft, I did not get how the solution works. Is
> there a step by step process to detect DAD attacks?
> 
> "MAC write or rewrite would not happen (no override bit set) - the mechanism
> proposed in this draft would not be activated."
> I suppose we agree on the current DAD, but I have no idea what the new
> algorithm does. Can you please add a section in the draft explaining the main
> DAD attack detection ideas?
> 
> Thanks,
> Dusan.
> 
> But node in DAD stage would not answer by NA, And node would not rise any
> flag (even with GRAND) at the time of DAD.
> MAC write or rewrite would not happen (no override bit set) - the mechanism
> proposed in this draft would not be activated.
> 
> > If DuplicityLevel=1 and after NS there is one NA, how does the host
> > know it is NOT an attack? One NA response can still be an attack.
> > On 2020-11-17, 1:40 PM, "Vasilenko Eduard"
> > If more responses then configured "DuplicityLevel" (that is
> > decremented on every NA received), Then block this IP address:
> > Clear all packets in the queue related to this target address. Log
> > duplicate address event with target address and both Link Layer
> > addresses (from received NA and from cache entry). Start DuplicateTimer for
> this Neighbor Cache entry. "
> > Intruder) would respond by NA that he does use this IP address. MAC
> > re-write would not happen - nothing to react.
> > If DAD would fail it's duty - it is not acceptable problem that needs ND
> redesign.
> > Hence, we could assume that DAD works.
> > Eduard
> > > Address collision is very rare. Most of the time the attacker would
> > > be the only one responding to multicated NS for DAD detection. What
> > > is the host supposed to do after this attack?
> > >
> > > Thanks,
> > > Dusan.
> > >
> > > > multiple responses? What is the host supposed to do when the
> > > > attack is discovered? How the attacker can be identified and blocked?
> > > >
> > > > On 2020-11-17, 10:28 AM, "ipv6 on behalf of Vasilenko Eduard"
> > > > <ipv6- [email-masked] on behalf of [email-masked]>
> wrote:
> > > >
> > > > Hi Philip,
> > > > It is not possible to force Intruder to do anything. Intruder
> > > > could send unicast NS with any possible flag set. He is intruder -
> > > > definitely out of any
> > > IETF restrictions.
> > > > Hence, router should sent multicast NS to give chance for victim
> > > > to reply, then router would see duplicity.
> > > >
> > > > By the way, in the absence of GRAND, Router would send multicast
> > > > NS anyway (after traffic would return from the Internet).
> > > > > > the way how security is done. Security is "the many layers
> > > > > > that Intruder should penetrate".
> > > > >
> > > > > break things ("Link Layer Address rewrite or initial write for
> > > > > any Neighbor Cache entry MUST be the result of only *multicast*
> > > > > Neighbor
> > > > > However, upon reflection there also seems to be a fundamental
> > > > > flaw in how this draft works.
> > > > >
> > > > > Today the attacker can send a point-to-point NS with source V
> > > > > and destination R and source link-layer address option with value MAC_A.
> > > > >
> > > > > Then, the idea is that the victim will also see this multicast
> > > > > and can generate an
> > > alert.
> > > > >
> > > > > "Solicited-Node multicast address are computed as a function of
> > > > > a "node's unicast and anycast addresses.  A Solicited-Node
> > > > > multicast "address is formed by taking the low-order 24 bits of
> > > > > an address "(unicast or anycast) and appending those bits to the
> > > > > prefix
> > > > > "When a multicast-capable interface becomes enabled, the node
> > > > > MUST "join the all-nodes multicast address on that interface, as
> > > > > well as "the solicited-node multicast address corresponding to
> > > > > each of the IP "addresses assigned to the interface.
> > > > >
> > > > > So the victim host does not listen to the solicited-node
> > > > > multicast address of the NS, because that packet goes to the
> > > > > router. So the victim will never know, unless the victim does
> > > > > not do multicast filtering (and
> > > > ------------------------------------------------------------------
> > > > -- IETF IPv6 working group mailing list [email-masked]
> > > > Administrative
> > > > Requests: