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

[Vasilenko Eduard <[e-mail]>]

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
> -----Original Message-----
> From: Mudric, Dusan [mailto:[e-mail]]
> Sent: 19 ноября 2020 г. 1:12
> To: Vasilenko Eduard <[e-mail]>; [e-mail]
> Subject: Re: [**EXTERNAL**] RE: New draft-vasilenko-6man-nd-mitm-
> protection - trust model
> 
> 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.
> 
> On 2020-11-18, 12:07 PM, "Vasilenko Eduard" <[e-mail]>
> wrote:
> 
> > -----Original Message-----
> > From: Mudric, Dusan [mailto:[e-mail]]
> > Sent: 18 ноября 2020 г. 1:25
> > To: Vasilenko Eduard <[e-mail]>; Philip Homburg
> > <pch- [e-mail]>; [e-mail]
> > Subject: Re: [**EXTERNAL**] RE: New draft-vasilenko-6man-nd-mitm-
> > protection - trust model
> >
> > 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.
> [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.
> >
> > Regards,
> > Dusan.
> >
> > On 2020-11-17, 1:40 PM, "Vasilenko Eduard"
> > <[e-mail]>
> > wrote:
> >
> > 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
> > > -----Original Message-----
> > > From: Mudric, Dusan [mailto:[e-mail]]
> > > Sent: 17 ноября 2020 г. 19:19
> > > To: Vasilenko Eduard <[e-mail]>; Philip Homburg
> > > <pch- [e-mail]>; [e-mail]
> > > Subject: Re: [**EXTERNAL**] RE: New draft-vasilenko-6man-nd-mitm-
> > > protection - trust model
> > >
> > > 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"
> > > <[e-mail]>
> > > wrote:
> > >
> > > 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
> > > > -----Original Message-----
> > > > From: Mudric, Dusan [mailto:[e-mail]]
> > > > Sent: 17 ноября 2020 г. 18:54
> > > > To: Vasilenko Eduard <[e-mail]>; Philip Homburg
> > > > <pch- [e-mail]>; [e-mail]
> > > > 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?
> > > >
> > > > is the algorithm protecting against DAD attacks?
> > > >
> > > > Thanks,
> > > > Dusan
> > > >
> > > > On 2020-11-17, 10:28 AM, "ipv6 on behalf of Vasilenko Eduard"
> > > > <ipv6- [e-mail] on behalf of [e-mail]>
> 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: [e-mail] [mailto:pch-b9D3CB0F5@u-
> > > > > 1.phicoh.com] On Behalf Of Philip Homburg
> > > > > Sent: 17 ноября 2020 г. 18:09
> > > > > To: [e-mail]
> > > > > Cc: Vasilenko Eduard <[e-mail]>
> > > > > 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 [e-mail]
> > > > Administrative
> > > > Requests:
> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
> > > > ip
> > > > v6
> > > > __;!!O
> > >
> >
> SsGDw!blQRTv4BqQkFOeKBoJDQq5j3MA7FeNpCZnNBY3CboPhC1m0ebd8aMRUl
> > > > vIET$
> > > > ------------------------------------------------------------------
> > > > --
> > >
> >
>