Internet DRAFT - draft-vasilenko-6man-nd-mitm-protection
draft-vasilenko-6man-nd-mitm-protection
IPv6 Maintenance (6man) Working Group E. Vasilenko
Internet Draft X. Xiao
Updates: 4861, 4862 (if approved) Huawei Technologies
Intended status: Standards Track September 24, 2020
Expires: March 2021
ND improvement to prevent Man-in-the-middle attack
draft-vasilenko-6man-nd-mitm-protection-00
Abstract
Privacy protection is the bigger and bigger concern of many
governments and public in general. ND has a few open man-in-the-
middle attack vectors. MITM is considered among the most dangerous
attack types because of information leakage. This document proposes
minimal modifications for ND to protect IPv6 nodes against still
open MITM attacks. It could be implemented gradually on any nodes,
with the biggest benefit from support on routers.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Vasilenko Expires March 24, 2021 [Page 1]
Internet-Draft ND-MITM-protection September 2020
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Terminology and pre-requisite..................................2
2. Introduction...................................................3
3. Security vulnerabilities.......................................4
3.1. Rewrite by unsolicited NA.................................4
3.2. Be the first and suppress DAD.............................5
3.3. Win the race just after DAD...............................6
3.4. Implications for off-link nodes...........................6
3.5. Speed up by [Gratuitous ND]...............................6
4. Solution - Security DAD........................................7
4.1. Standards modifications...................................8
4.1.1. Modifications to [ND]................................8
4.1.2. Modifications to [SLAAC]............................11
4.2. Interoperability analysis................................11
5. Applicability analysis........................................13
5.1. Performance analysis.....................................13
5.2. Usability analysis.......................................15
5.3. DoS level analysis.......................................16
6. Security Considerations.......................................16
7. IANA Considerations...........................................16
8. References....................................................17
8.1. Normative References.....................................17
8.2. Informative References...................................18
9. Acknowledgments...............................................18
1. Terminology and pre-requisite
Good knowledge and frequent references to [ND] is assumed. Many
terms are inherited from [ND]. Additional terms are introduced:
Security DAD: Duplicated Address Detection for security check
at the time to write or rewrite for Link Layer Address
Intruder: The Node under control of malicious 3rd party
Vasilenko Expires March 24, 2021 [Page 2]
Internet-Draft ND-MITM-protection September 2020
Intercepted Victim: The node that could lose the privacy of
communication
Poisoned Victim: The node that could suffer an unauthorized
modification of Neighbor Cache entry; depending on the
scenario, it could additionally lose the privacy of
communication
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here
2. Introduction
Cyber Security is one of the biggest concern for many governments:
CPNI, HIPAA, FCRA, ECPA in US; GDPR in Europe; CSL in China; DPB in
India; Data Protection Act 2018 in the UK. Many regulations have
been refreshed or fully redeveloped in recent years.
[ND Trust Model] clearly states: "it is desirable to limit the
amount of potential damage in the case a node becomes compromised.
For example, it might still be acceptable that a compromised node is
able to launch a denial-of-service attack, but it is undesirable if
it is able to hijack existing connections or establish man-in-the-
middle attacks on new connections."
The most dangerous and easy way to organize a MITM attack is based
on rogue Router Advertisements. Fortunately, rogue router is easy to
block on link level device by filtering ICMPv6 message type 134
([RA-Guard]).
This document discusses MITM attacks that are more difficult to
block, because it is a challenge for link layer to clarify IP
address ownership in the plain (distributed) ND architecture. The
Internet has open tools to exploit this vulnerability (parasite6,
scapy). Attacks are explained in [RIPE-Training] and [IEEE ND
Security]. Last reference has very big collection of ND security
improvements proposed (50+ solutions), but the problem related to
information leakage is still open.
This document proposes a simple modification for ND protocol that
could be briefly explained as:
Vasilenko Expires March 24, 2021 [Page 3]
Internet-Draft ND-MITM-protection September 2020
o 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.
o "Security DAD" is mandatory: it SHALL be checked that not more
than expected number of NA replies have been received in the
response to *multicast* NS. It means that for the majority of
cases (default DuplicityLevel): no more than 1 reply.
o Any node SHOULD override neighbor cache entry on routers by
sending unsolicited NA message after respective node addresses
would progress to preferred state.
3. Security vulnerabilities
3.1. Rewrite by unsolicited NA
Let's consider the case when all nodes support [ND] without any
extensions. Additionally, assume that Intruder gains access to one
node on the link by exploiting some other vulnerability or Intruder
has connected his host physically to the link.
3 nodes involved in the attack: Intruder (typically a host),
Intercepted Victim (typically another host) and Poisoned Victim
(typically a router).
Neighbor Cache poisoning could be organized (by the procedure below)
for any node (host or router). Router is typically the more probable
target for the Poisoned Victim role because Intercepted Victim has a
high probability to communicate with a Router.
The algorithm for attack:
o Intruder has many ways to get Intercepted Victim IP address - see
[IPv6 Reconnaissance]. The IP address could not be considered
hidden information.
o Intruder starts sending non-legitimate unicast NA to Poisoned
Victim with the "target IP address" of Intercepted Victim, but
link layer address of the Intruder, with flags "Override" and
"Solicited" set.
Vasilenko Expires March 24, 2021 [Page 4]
Internet-Draft ND-MITM-protection September 2020
o If Neighbor Cache entry on Poisoned Victim for reachability to
Intercepted Victim is already created (by NS or return traffic -
the second one is highly probable for routers) - then the
Neighbor Cache entry would be overwritten, because "Override"
flag was set. Neighbor cache entry would be put to STALE state at
a minimum. If a particular implementation does not track
correspondence between NS and NA (not required for state machine
in [ND]) then cache entry would be put directly to REACHABLE,
because "Solicited" flag was set (section 7.2.5 of [ND]).
o Intercepted Victim would not see unicast NA - it would not have
chance to recognize "duplicate address". Upstream traffic would
flow normally from Intercepted Victim to Poisoned Victim, but
downstream traffic would go from Poisoned Victim to Intruder. An
Intruder could build a much bigger set of attacks on this
basement, for example: it could edit DNS answers and redirect all
Intercepted Victim's traffic to itself (both directions).
An intruder could send poisoning NA periodically and intercept
traffic as soon as it would become available from Poisoned Victim.
Initial traffic missed for Intruder could be very small (tens of
milliseconds).
3.2. Be the first and suppress DAD
An Intruder could claim an IP address (and establish communication)
while Intercepted Victim is disconnected from the link. Intruder
just needs to suppress DAD on itself - Poisoned Victim would never
understand that address duplication did happen for the basic [ND]
environment.
It is a more difficult attack vector for an Intruder, because it
needs to wait Intercepted Victim reconnection to the link.
It would be difficult to push the router to reinitialize the link.
It is potentially possible to influence the host to re-initialize
the link by DoS, social engineering or other vulnerability. It is
definitely possible to wait till host or router would reload after
upgrade (predicted event for host).
This attack vector does not make sense for the Intruder under the
case of availability attack vector #1. But it could become next
primary attack vector if Intruder would be prevented from attack
vector #1. Hence, solution should block it too.
Vasilenko Expires March 24, 2021 [Page 5]
Internet-Draft ND-MITM-protection September 2020
3.3. Win the race just after DAD
The Intruder could be silent and monitor DAD. As soon as the
Intruder would see DAD - it would have RetransTimer (1sec by
default) to persuade the Poisoned Victim that it is the only one on
the link that claims this IP address. The Intruder could pass any
multicast or unicast check, because Intercepted Victim would be
silent inside the DAD procedure for the basic [ND] environment.
It is a more difficult attack vector for an Intruder, but could
become primary if other attack vectors would be blocked. See more
detailed explanation in previous section.
3.4. Implications for off-link nodes
All 3 attack vectors above have additional strong vulnerability
consequence that make sense to discuss separately: Intruder
impersonates Intercepted Victim for traffic from off-link (for
connections initiated from any node behind the router). It is the
strongest form of 2-way Man-in-the-middle attack.
It is not very important for ordinary hosts, because not many remote
nodes would try to contact Intercepted Victim. There is the
possibility for unlucky exception when admin would come to
Intercepted Victim for remote monitoring, then Intruder could ask
him for password hash. Admin password is extremely valuable for the
Intruder.
It is really big leakage of information if Intruder impersonates
some important corporate server. Many users of this company would
connect to the Intruder. The majority of internal Enterprise
applications do not have mutual authentication properly activated.
The Intruder would be capable to collect many passwords of this
company. It is easy for Intruder to emulate the original application
because it could proxy user requests to Intercepted Victim (on the
same link) and get proper responses that fully satisfy users.
Particular application could have additional vulnerabilities that is
easy to exploit in the situation when Intruder is on the server
side.
3.5. Speed up by [Gratuitous ND]
This is not separate attack vector. It is just a little improvement
for the Intruder for attack vectors #1.
Let's assume that [Gratuitous ND] is implemented at least on
Poisoned Victim.
Vasilenko Expires March 24, 2021 [Page 6]
Internet-Draft ND-MITM-protection September 2020
[Gratuitous ND] has changed 1st paragraph of [ND] section 7.2.5 - it
permits creation of new Neighbor Cache entry on Poisoned Victim,
including the situation when there was no NS before and no record
has been created in any state.
Let's assume that garbage collector deleted stale record for seldom
speaking node. Then consider situation of attack vector #1. Basic
[ND] pushes the Intruder to send unsolicited NA frequently (up to
the rate limit on the Poisoned Victim). In contrast, [Gratuitous ND]
permits to create the neighbor cache record by one message much in
advance of traffic flow. As a result, Intruder could get all traffic
from Poisoned Victim to Intercepted Victim, no any packet would be
missed. The improvement for the Intruder is very small - just tens
of milliseconds of additional traffic would be intercepted. Attack
vector is very effective in both cases.
Let's look to the attack vector #2. Intruder had plenty of time to
establish communication by normal traffic flow. No additional value
from [Gratuitous ND].
Let's look to the attack vector #3. Intruder have RetransTimer (1sec
by default) to create a record on Poisoned Victim. Normally
generated traffic should be fast enough. No additional value from
[Gratuitous ND] again.
4. Solution - Security DAD
The general idea is very easy to explain:
o 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.
o "Security DAD" is mandatory: it SHALL be checked that not more
than expected number of NA replies have been received in the
response to *multicast* NS. It means that for the majority of
cases (default DuplicityLevel): no more than 1 reply.
o Only fastest NA response to multicast NS SHOULD be used for write
or rewrite of LLA. This rule would be useful only for the case of
DuplicityLevel more than 1 (not default configuration). It is
needed to support many anycast address on the same link.
Vasilenko Expires March 24, 2021 [Page 7]
Internet-Draft ND-MITM-protection September 2020
o Any node SHOULD override neighbor cache entry on routers by
sending unsolicited NA message after respective node addresses
would progress to preferred state.
The implementation is more complex, because it needs to be put into
[ND] context - see next sections.
4.1. Standards modifications
4.1.1. Modifications to [ND]
* Section 5.1 and section 7.3.2 of [ND],
add new state of Neighbor Cache entry:
DUPLICATE - Target address has been put into dampening state for the
time defined by DuplicateTimer, because SDAD (additional
security check) has found duplicate address. The Neighbor
Cache entry MUST not be used for traffic forwarding. All NS
and NA for this target address SHALL be ignored. DUPLICATE
entry SHOULD be deleted when DuplicateTimer expire.
* Sections 6.2.1 and 6.3.2 of [ND],
add to router and host variables:
DuplicateTimer - measured in seconds, dampening time for duplicate
IP address discovered by SDAD procedure. It SHOULD be
copied from "Reachable Time" advertised by router (on the
router itself, it is known as AdvReachableTime - section
6.2.1 of [ND]). Future versions of [ND] should be extended
to advertise this timer from router in RA messages.
* Sections 6.2.1 and 6.3.1 of [ND],
add to router and host configurable variables:
DuplicityLevel - number of NA responses that is accepted as
legitimate for multicast NS solicitation. It permits to
proper handling of anycast addresses present on the link if
the maximum number of anycast addresses is known in
advance. The node MUST have the capability to provision
DuplicityLevel on a per-link granularity. 32-bit unsigned
integer SHOULD be reserved for this counter.
Vasilenko Expires March 24, 2021 [Page 8]
Internet-Draft ND-MITM-protection September 2020
* Section 10 of [ND], add to Node constants:
DuplicityLevel 1 (no duplicate addresses permitted)
* Section 5.3 (Garbage Collection) of [ND], add at the end:
Neighbor Cache entries with DuplicateTimer expired SHOULD be
deleted. It is possible to delete entries before timer expiration,
if there is a need to free space for new entries.
* Section 7.2.2 (Sending NS) of [ND], add at the end:
Prepare state machine on every transmission of multicast NS:
o Initialize DUPLICITY counter by DuplicityLevel
o Restart RetransTimer of this Neighbor Cache entry
Do not change RetransTimer for unicast NS - reuse expired one.
* Section 7.2.5 (Receipt NA) of [ND], replace at the beginning:
This modification is equivalent to [Gratuitous ND]. You could have
this change already if [Gratuitous ND] is implemented on your
router.
OLD TEXT:
When a valid Neighbor Advertisement is received (either solicited or
unsolicited), the Neighbor Cache is searched for the target's entry.
If no entry exists, the advertisement SHOULD be silently discarded.
There is no need to create an entry if none exists, since the
recipient has apparently not initiated any communication with the
target.
NEW TEXT:
Vasilenko Expires March 24, 2021 [Page 9]
Internet-Draft ND-MITM-protection September 2020
When a valid Neighbor Advertisement is received (either solicited or
unsolicited), check first for the target's IP address entry in the
Neighbor Cache.
If no entry exists on the host, it SHOULD silently discard this
advertisement. There is no need to create an entry if none exists,
since the recipient has apparently not initiated any communication
with the target.
If no entry exists on the router, it should additionally check for
Target link-layer address option.
If the received Neighbor Advertisement does not contain the Target
link-layer address option, then the router SHOULD silently discard
this advertisement. Else router SHOULD create a new entry for the
target address with the link-layer address set to the Target link-
layer address option. The neighbor cache entry state MUST be set to
STALE.
* Section 7.2.5 (Receipt NA) of [ND], add at the end:
I. If NA received is inside RetransTimer window, then it is
considered as a response to NS (solicited):
o If DUPLICITY counter does not yet reach 0: Process NA according
to all other rules of this section, except write or rewrite of
link layer addresses is permitted only if DUPLICITY is equal to
DuplicityLevel (only fastest anycast is used for neighbor
reachability cache). Additionally, decrement DUPLICITY.
o 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.
II. If RetransTimer is expired or Neighbor Cache entry does not
exist yet for this target address then NA is considered unsolicited
disregard of any flags set. Process NA according to all other rules
of this section, except additional check: if processing would need
to initial write or rewrite Link Level Address (i.e. any change of
LLA) then change Neighbor Cache entry state to INCOMPLETE and
initiate *multicast* Neighbor Solicitation process against this
target IP address.
Vasilenko Expires March 24, 2021 [Page 10]
Internet-Draft ND-MITM-protection September 2020
* 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.
* It MAY be added after 4th paragraph of section 5.2 (Conceptual
Sending Algorithm) of [ND]:
Traffic resolved to be sent through Neighbor Cache entry in
DUPLICATE state MUST be dropped.
4.1.2. Modifications to [SLAAC]
* Neighbor Cache maintenance is pretty much restricted to [ND].
Hence, it is not mandatory to change [SLAAC] - the latter is more
concerned on initialization and DAD. One optimization is possible
specifically for [Gratuitous ND] environment. It is stated in
paragraph 4 of section 5.4.2 [SLAAC] that messages sent in response
to multicast announcements should be delayed for random time between
0 and MAX_RTR_SOLICITATION_DELAY, but the type of multicast message
is mentioned in clear "router advertisement message". It MAY be
reasonable to replace it to "any message", because [Gratuitous ND]
does send unsolicited NA to all-routers multicast and this document
proposes response by NS that could synchronize from all routers.
4.2. Interoperability analysis
Proposed solution does not need any additional functionality on link
layer technology (no layer 2 features needed).
It does not block unsolicited NA - Link Local Addresses write or
rewrite is still possible, including compatibility to [Gratuitous
ND].
[Optimistic DAD] creates possibility for Intruder to intercept
RetransTimer (1sec by default) of traffic in the case of attack
vector #2 and #3, because optimistic address could transmit traffic
without the possibility to override Poisoned Victim neighbor cache -
NA should have override flag cleared. [Gratuitous ND] does not
change this rule for the good reason: it would be not a good idea to
strongly claim address that has not passed DAD check yet.
Vasilenko Expires March 24, 2021 [Page 11]
Internet-Draft ND-MITM-protection September 2020
Hence, SDAD would not be activated up to the time the address would
progress to preferred, that initiate NA with override flag set.
You could disable [Optimistic DAD] if your concern about traffic
intercepted for RetransTimer seconds is bigger than your concern of
interface initialization delay for the same time.
[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 flag set) is
proposed.
It should be no problem for multi-prefix and multi-homing
environment discussed in [Multi-Homing], because Neighbor Cache
population does not influence forwarding directions (Destination
Cache does). [Gratuitous ND] could create unnecessary states on
routers advertising address spaces from different ISP for the case
of Provider-aggregatable address space. Mechanism specified in this
document would confirm it to REACHABLE state, then it would be
probably not used later (freeze in STALE state up to garbage
collection). It is very small deficiency originated by [Gratuitous
ND] that does not make sense to fix.
This document does not create any problem for standard update
proposed in [Subnet Model], because determination of "on-link"
addresses is on Destination Cache level that Neighbor Cache is not
capable to influence.
[FCFS SAVI] deep security assistance from L2 switches would not
benefit from this document - it is not possible to poison cache in
SAVI architecture. It is important to mention that this document
would not create any interoperability issue with [FCFS SAVI]. There
would be no illegal write or rewrite requests (with duplicate
addresses) that SDAD needs to check.
The same consequence is under SeND presence: cryptographically
protected addresses does not need additional protection, but again
current document would not create any interoperability problem by
additional Security DAD check.
DHCP support is not affected by this document - it is irrelevant how
node has got an IP address. Furthermore, it is not important whether
it has been done in a legal way - if Intruders would try to hijack
traffic of each other - they would be both blocked, because they
would create duplicate addresses.
Vasilenko Expires March 24, 2021 [Page 12]
Internet-Draft ND-MITM-protection September 2020
[NUD improvement] has the natural synergy with current document,
because it converts unicast NS to multicast NS (when neighbor cache
state would change to UNREACHABLE) that permits to save on
additional multicast NS for SDAD check.
SDAD (as well as ordinary DAD) is not fully compatible to anycast IP
address. DuplicityLevel permits to properly handle anycast addresses
present on a link if the maximum number of anycast addresses is
known in advance (see DuplicityLevel variable).
Active-Standby clustering solutions (including VRRP) should not be
affected by this standard extension, because properly functioning
cluster should respond to target IP only from one LLA. If any
concern on cluster behavior exist - SDAD could be effectively
disabled by setting bigger number for DuplicityLevel.
The document proposes minimal changes for ND protocol without
changing the basic principles. Moreover, changes in nodes behavior
are local - it is not needed to wait for formal standard update -
new behavior would be fully compliant to [ND] and [SLAAC], as well
as all other extensions mentioned above in this section.
5. Applicability analysis
5.1. Performance analysis
[Gratuitous ND] cache initialization improvement is not affected by
this document, because algorithm above assumes immediate check, no
need to wait for return traffic to be buffered.
Additional Security DAD (with associated multicast solicitation)
should happen only for Link Layer Address write or rewrite that
ideally should happen only one time for every address. Control Plane
load should not be considerably increased. Moreover, in some cases
SDAD check coincide with multicast NS that results in no additional
messages. See later more detailed analysis of multicast performance
for 3 primary scenarios. It has been analyzed per 1 address space,
other Global Unicast Addresses or Unique Local Address would have
exactly the same calculations.
LLA would generate additional multicast traffic that is omitted in
calculations.
A reminder: according to section 5.1 of [SLAAC] - ordinary DAD has 1
multicast check by default (DupAddrDetectTransmits is 1).
Vasilenko Expires March 24, 2021 [Page 13]
Internet-Draft ND-MITM-protection September 2020
We could assume that the host would not wait scheduled RA, it would
probably initiate RS that would generate multicast RA.
1. Host to host communication (general scenario).
The basic neighbor reachability detection (by [RFC 4861]) should
use one multicast for DAD and one multicast solicitation to
discover other node. It is not important for performance analysis
that only originating node would check 2-way communication (and
would promote cache entry to REACHABLE) as a result of initial
multicast solicitation, because other node would record proper
LLA too - it would use unicast solicitation later to prove 2-way
communication. Hence, this document would generate an additional
multicast request per every pair of communicating nodes.
Depending on the mesh communication richness between nodes - it
could increase multicast traffic from 0 up to 100% (depends on
the number of communicating pairs): (2*c*(c-1)+h)/(c*(c-1)+h).
2. Router cache population in the basic [ND] scenario.
Initial DAD is omitted here, because it was calculated in host-
to-host scenario. The host would generate multicast RS and would
receive multicast RA. Multicast NS is assumed as a result of one
router receiving traffic to a particular host. This document
reuses any multicast NS for SDAD, hence performance is not
affected: (h*(2*r+1))/(h*(2*r+1))=1.
3. Router cache population in the scenario of [Gratuitous ND].
Initial DAD is omitted here, because it was calculated in host-
to-host scenario. The host would generate multicast RS and would
receive multicast RA. One multicast unsolicited NA is proposed by
[Gratuitous ND], it could not be used for SDAD, because it is
going to different multicast group (routers). Hence, this
document creates 33% more multicast traffic for 1 router on this
link, 40% more multicast for 2 routers on this link, up to 50%
more multicast for many routers: (h*(2*r+1+r))/(h*(2*r+1)).
It makes sense to remind, that normal neighbor cache entry
refreshment should not generate additional multicast, because entry
refreshment is assumed in unicast to known MAC address - see PROBE
definition in [ND] section 5.1. The Garbage collector may completely
delete long stale neighbor cache entry (good example of such host is
a printer), then multicast would be needed anyway - this document
does not increase multicast for that case.
Vasilenko Expires March 24, 2021 [Page 14]
Internet-Draft ND-MITM-protection September 2020
5.2. Usability analysis
Host's Unsolicited NA (after address would go to preferred state) is
proposed only in the direction of all-routers multicast (router to
host communication). It would invoke SDAD check and reveal
duplicity.
Attack vector #2 has been left unprotected by this document for the
case of host to host communication. MITM for traffic inside link is
still possible, because SDAD check is useless at the time when
Intercepted Victim is not connected yet to the link, but later would
be no rewrite request that would not initiate SDAD check.
Some technologies are prone to multicast loss. The mechanism in this
document may not give security protection as intended if multicast
NS would be lost only in the direction of Intercepted Victim - SDAD
would not detect address duplicity.
The Intruder could potentially answer to multicast NS a few
milliseconds faster than the Intercepted Victim. Poisoned Victim
could update neighbor cache in the favor of Intruder and release the
small portion of the traffic before Poisoned Victim would receive
excessive number of NA responses and block both (Intruder and
Intercepted Victim).
Security solution discussed in this document does not need any
coordination on introduction in production. It could be done in any
order or ad-hoc: it is not restricted which one particular node
(router or host) would start additional SDAD check first.
There are 2 primary use cases envisioned (with the 3rd mixing both):
o Campus environment: the majority of traffic are going to default
router on every link. The intruder would have the priority to
poison router cache. Hence, router protection is priority
o Data Center environment: the big proportion of the East-West
traffic. Hosts protection has bigger priority for this use case
DuplicityLevel is the common information for the link - it is better
to advertise it from router in the future versions of ND. Current
design choice (keep this information local) is justified to simplify
transition - possibility to introduce SDAD support on any one node
or node sets in any order.
Vasilenko Expires March 24, 2021 [Page 15]
Internet-Draft ND-MITM-protection September 2020
5.3. DoS level analysis
MITM attack vector #1 was very effective and easy to organize, hence
it was very probable. It has been converted by this document into
the same probable DoS (Intercepted Victim and Intruder - both
blocked). 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 of catching server with popular application in reload or
upgrade state - then legal node would be blocked. The Intruder would
be capable of pretending to be the particular application and start
collection of valuable information from users that would visit this
application. See section 3.4 (Implications for off-link nodes) for
details. It is the leakage of information again. The leakage of
information is considered much more serious security problem than
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.
6. Security Considerations
This document describes the conversion of most common MITM attack
vectors into less dangerous DoS. It does not introduce new
vulnerabilities.
One corner case is left unprotected by this document:
attack vector #2 for the situation when all involved nodes are hosts
and at the same time Intercepted Victim has been connected to the
link later after Intruder.
7. IANA Considerations
This document has no any request to IANA.
Vasilenko Expires March 24, 2021 [Page 16]
Internet-Draft ND-MITM-protection September 2020
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, <https://www.rfc-
editor.org/info/rfc4861>.
[SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, DOI
10.17487/RFC4862, September 2007, <https://www.rfc-
editor.org/info/rfc4862>.
[Gratuitous ND] Linkova, J., "Gratuitous Neighbor Discovery:
Creating Neighbor Cache Entries on First-Hop Routers",
draft-ietf-6man-grand-01 (work in progress), July 2020.
[Optimistic DAD] N. Moore, "Optimistic Duplicate Address Detection
(DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April
2006, <https://www.rfc-editor.org/info/rfc4429>.
[Multi-Homing] F. Baker, B. Carpenter, "First-Hop Router Selection
by Hosts in a Multi-Prefix Network", RFC 8028, DOI
10.17487/RFC8028, November 2016, <https://www.rfc-
editor.org/info/rfc8028>.
[ND Trust Model] P. Nikander, J. Kempf, E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, DOI
10.17487/RFC3756, May 2004, <https://www.rfc-
editor.org/info/rfc3756>.
[NUD improvement] E. Nordmark, I. Gashinsky, "Neighbor
Unreachability Detection Is Too Impatient", RFC 7048, DOI
10.17487/RFC7048, July 2010, <https://www.rfc-
editor.org/info/rfc7048>.
Vasilenko Expires March 24, 2021 [Page 17]
Internet-Draft ND-MITM-protection September 2020
[Subnet Model] H. Singh, W. Beebee, E. Nordmark, "IPv6 Subnet Model:
The Relationship between Links and Subnet Prefixes", RFC
5942, DOI 10.17487/RFC5942, July 2010, <https://www.rfc-
editor.org/info/rfc5942>.
[FCFS SAVI] E. Nordmark, M. Bagnulo, E. Levy-Abegnoli, "FCFS SAVI:
First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", RFC
6620, DOI 10.17487/RFC6620, May 2012, <https://www.rfc-
editor.org/info/rfc6620>.
8.2. Informative References
[RFC8200] S. Deering, R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 8200, DOI 10.17487/RFC8200,
July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RIPE-Training] RIPE NCC, "IPv6 Security Training", February 2019,
<https://www.ripe.net/support/training/material/ipv6-
security/ipv6security-slides.pdf>.
[RA-Guard] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI
10.17487/RFC6105, February 2011, <https://www.rfc-
editor.org/info/rfc6105>.
[IPv6 Reconnaissance] F. Gont, T. Chown, "Network Reconnaissance in
IPv6 Networks", RFC 7707, DOI 0.17487/RFC7707, March 2016,
<https://www.rfc-editor.org/info/rfc7707>.
[IEEE ND Security] Amjed Sid Ahmed Mohamed Sid Ahmed, Rosilah
Hassan, Nor Effendy Othman, "IPv6 Neighbor Discovery
Protocol Specifications, Threats and Countermeasures: A
Survey", DOI 10.1109/ACCESS.2017.2737524, August 2017,
<https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=
8022867>.
9. Acknowledgments
Thanks to 6man working group for problem discussion
Vasilenko Expires March 24, 2021 [Page 18]
Internet-Draft ND-MITM-protection September 2020
Authors' Addresses
Eduard Vasilenko
Huawei Technologies
17/4 Krylatskaya st, Moscow, Russia 121614
Email: vasilenko.eduard@huawei.com
Xiao Xipeng
Huawei Technologies
205 Hansaallee, 40549 Dusseldorf, Germany
Email: xipengxiao@huawei.com
Vasilenko Expires March 24, 2021 [Page 19]
