RE: New draft-vasilenko-6man-nd-mitm-protection-00.txt

[Vasilenko Eduard <[e-mail]>]

Hi Fernando,
I have looked carefully into draft-ietf-opsec-ipv6-nd-security-00

It has small section 6.1.1 that is related to discussed topic (half a page).
It does not discuss in details attack vectors. It does not mention information leakage.
It proposes only one solution that is not compatible to "unsolicited NA" (not to permit to change MAC till reachability would expire) - it would break any clustering technology. It would not prevent MITM when server would go to reload.

You do use term "hijack" in this document for the leakage of information.
In reality "hijack" is about intercepting active flows that is not effective anymore on 70-80% of encrypted traffic (except very vulnerable DNS still not encrypted in majority of cases).
MITM is to be proxy during session initiation, when key/certificates should be accepted - it is still very possible to have MITM, many corporate resources are not properly connected to certification authorities. User would accept whatever pop up window with request "do you trust this key?".

Small section 6.3.1 is about MITM based on rogue NA  (half a page).
It does not discuss details. It does not propose any solution.
No reference that L2 switch is responsible for the solution of this problem.

That's it.
My draft discusses the problem of "rogue NA" much deeper (20x) and proposes solution on ND level.

Eduard
> -----Original Message-----
> From: Vasilenko Eduard
> Sent: 28 сентября 2020 г. 14:28
> To: 'Fernando Gont' <[e-mail]>; Fernando Gont
> <[e-mail]>; [e-mail]
> Subject: RE: New draft-vasilenko-6man-nd-mitm-protection-00.txt
> 
> Fernando,
> > The point is that you simply can't address all ND-based MITM vectors
> > -- basically because ND has been designed with the premise that you trust your
> neighbors.
> Read the draft. I believe that rogue NA is blocked.
> 
> > Additionally, if you require layer-2 cooperation to address some of
> > them, I'm not sure why you'd not require cooperation to address all of them.
> No need for L2 cooperation for MITM based on rogue NA - it is solved just on
> ND level by current draft.
> 
> > Not sure what you mean: DHCP snooping is the equivalent of RA-guard.
> No.
> DHCP snooping creates ARP filtering table dynamically (for all ports).
> RA-guard is static filter (router ports are at the stable location). RA-guard is very
> simple and easy to implement.
> 
> > Please see draft-ietf-opsec-nd-security.
> OK. later
> 
> > However, you wither trust your neighbors, or you don't.
> The life is in general not always black and white. Some things are more
> complicated (like distributed ND) - other possibilities exist.
> 
> Ed/
> > -----Original Message-----
> > From: Fernando Gont [mailto:[e-mail]]
> > Sent: 28 сентября 2020 г. 14:03
> > To: Vasilenko Eduard <[e-mail]>; Fernando Gont
> > <[e-mail]>; [e-mail]
> > Subject: Re: New draft-vasilenko-6man-nd-mitm-protection-00.txt
> >
> > Hello, Eduard,
> >
> > On 28/9/20 07:13, Vasilenko Eduard wrote:
> > > Hi Fernando,
> > >> If you consider RA-guard a mitigation for RA-based attacks, then,
> > >> things like "First Hop Security"/ND inspection/SAVI would solve the
> > >> ND
> > counterpart.
> > > I have not understood what you mean by "First Hop Security"/ND
> > > inspection" -
> > it looks as very general term.
> >
> > See e.g.:
> > https://www.cisco.com/c/en/us/td/docs/ios-
> > xml/ios/ipv6_fhsec/configuration/15-sy/ip6-nd-inspect.html
> >
> >
> >
> > > I agree that SAVI deep assistance from L2 could be an alternative to
> > > what I am proposing in the draft. But
> > > - it is very complicated and expensive on switches, available only
> > > on small portion of vendors
> > > - it is better to fix L3 problem at L3 (if possible - I do not know
> > > how to fix RA MITM without simple filtering on switch)
> > > - 1st could be intruder, then SAVI would not block MITM: all users
> > > (from other subnets) would contact server and show credentials to
> > > intruder
> >
> > The point is that you simply can't address all ND-based MITM vectors
> > -- basically because ND has been designed with the premise that you trust your
> neighbors.
> >
> > Additionally, if you require layer-2 cooperation to address some of
> > them, I'm not sure why you'd not require cooperation to address all of them.
> >
> >
> >
> > > I do not agree that IPv4 and IPv6 are equal on ND/ARP security.
> > > IPv4 has DHCP - it is possible to snoop all messages and do
> > > filtering on the
> > switch. It is simple and widely supported by switches.
> > > IPv6 has no centralized authority to snoop, solution should be much
> > > more
> > complex like SAVI. Hence, it is not widely supported by switch vendors.
> >
> > Not sure what you mean: DHCP snooping is the equivalent of RA-guard.
> > FHS is the equivalent of ARP policing.
> >
> >
> > > Reference to "Trusted model" does not explain anything. Because this
> > > RFC has
> > forgotten to document all attack vectors discussed in my current draft.
> >
> > Please see draft-ietf-opsec-nd-security.
> >
> >
> >
> > > Any MITM is the leakage if information, because man-in-the-middle is
> > > capable
> > to record and even change it.
> >
> > MITM does not necesarily imply information leakage.
> >
> >
> >
> > > I do reference in the draft that encrypted authentication is the
> > > solution that
> > supersede this draft by security protection.
> > > Just one problem: it has been refused by the market.
> >
> > Indeed.
> >
> > However, you wither trust your neighbors, or you don't.
> >
> > Thanks,
> > --
> > Fernando Gont
> > SI6 Networks
> > e-mail: [e-mail]
> > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >