Reviewer: Jean-Michel Combes
Review result: Almost Ready
Hi,
Please find my review, as member of the INT Area Directorate, of the following
document:
*** GENERAL COMMENT(S)/QUESTION(S) ***
o Forwarding a packet
I am not aware of EVPN mechanisms: for this review, I am assuming that EVPN
allows a PE to forward a packet when the CE owning the MAC destination address
and the CE owning the MAC source address are not on the same L2 link. If my
assumption is wrong, that should change deeply my review.
o State of the art
There are no reference to RFC 4349 and RFC 6957, at least.
Previous works have been done on “Proxy-ND” and potential issues already
analyzed/solved. Please my comments/questions inside: - Section 3.6 - Section 6
*** DEEP REVIEW ***
BESS Workgroup J. Rabadan, Ed.
Internet-Draft S. Sathappan
Updates: 7432 (if approved) K. Nagaraj
Intended status: Standards Track G. Hankins
Expires: July 11, 2021 Nokia
T. King
DE-CIX
January 7, 2021
Operational Aspects of Proxy-ARP/ND in EVPN Networks
draft-ietf-bess-evpn-proxy-arp-nd-11
<snip>
1. Terminology
<snip>
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
BUM: Broadcast, Unknown unicast and Multicast layer-2 traffic.
BD: Broadcast Domain.
ARP: Address Resolution Protocol.
GARP: Gratuitous ARP message.
ND: Neighbor Discovery Protocol.
NS: Neighbor Solicitation message.
NA: Neighbor Advertisement.
IXP: Internet eXchange Point.
IXP-LAN: the IXP's large Broadcast Domain to where Internet routers
are connected.
DC: Data Center.
IP->MAC: an IP address associated to a MAC address. IP->MAC entries
are programmed in Proxy-ARP/ND tables and may be of three different
types: dynamic, static or EVPN-learned.
SN-multicast address: Solicited-Node IPv6 multicast address used by
NS messages.
NUD: Neighbor Unreachability Detection, as per [RFC4861].
DAD: Duplicate Address Detection, as per [RFC4861].
SLLA: Source Link Layer Address, as per [RFC4861].
TLLA: Target Link Layer Address, as per [RFC4861].
R Flag: Router Flag in NA messages, as per [RFC4861].
O Flag: Override Flag in NA messages, as per [RFC4861].
S Flag: Solicited Flag in NA messages, as per [RFC4861].
RT2: EVPN Route type 2 or EVPN MAC/IP Advertisement route, as per
[RFC7432].
MAC or IP DA: MAC or IP Destination Address.
MAC or IP SA: MAC or IP Source Address.
AS-MAC: Anti-spoofing MAC.
LAG: Link Aggregation Group.
BD: Broadcast Domain.
<JMC>
BD is already defined at the beginning of the list.
</JMC>
<snip>
3. Solution Description
<snip>
As PE3 learns more and more host entries in the Proxy-ARP/ND table,
the flooding of ARP Request messages is reduced and in some cases it
can even be suppressed. In a network where most of the participant
CEs are not moving between PEs and they advertise their presence with
GARPs or unsolicited NA messages, the ARP/ND flooding as well as the
unknown unicast flooding can practically be suppressed. In an EVPN-
based IXP network, where all the entries are Static, the ARP/ND
flooding is in fact totally suppressed.
<JMC>
IMHO, it is not possible to suppress ALL ND flooding: Duplicate Address
Detection (DAD) is remaining, even when the entries are all Static: cf. RFC
4862, Section 5.4. </JMC>
The Proxy-ARP/ND function can be structured in six sub-functions or
procedures:
1. Learning sub-function
2. Reply sub-function
3. Unicast-forward sub-function
4. Maintenance sub-function
5. Flooding reduction/suppression sub-function
6. Duplicate IP detection sub-function
A Proxy-ARP/ND implementation MAY support all those sub-functions or
only a subset of them. The following sections describe each
individual sub-function.
<JMC>
No sub-function is mandatory to have “Proxy-ARP/ND” working correctly?
If not, please, add text saying which ones MUST be implemented.
</JMC>
<snip>
3.2. Reply Sub-Function
This sub-function will reply to Address Resolution requests/
solicitations upon successful lookup in the Proxy-ARP/ND table for a
given IP address. The following considerations should be taken into
account:
a. When replying to ARP Request or NS messages, the PE SHOULD use
the Proxy-ARP/ND entry MAC address as MAC SA. This is
RECOMMENDED so that the resolved MAC can be learned in the MAC
FIB of potential layer-2 switches sitting between the PE and the
CE requesting the Address Resolution.
<JMC>
What is the IP source address in the NA message?
What is the Target link-layer address in the NA message?
</JMC>
<snip>
3.3. Unicast-forward Sub-Function
As discussed in Section 3.2, in some cases the operator may want to
'unicast-forward' certain ARP-Request and NS messages as opposed to
reply to them. The operator SHOULD be able to activate this option
with one of the following parameters:
a. unicast-forward always
b. unicast-forward unknown-options
If 'unicast-forward always' is enabled, the PE will perform a Proxy-
ARP/ND table lookup and in case of a hit, the PE will forward the
packet to the owner of the MAC found in the Proxy-ARP/ND table. This
is irrespective of the options carried in the ARP/ND packet. This
option provides total transparency in the BD and yet reduces the
amount of flooding significantly.
If 'unicast-forward unknown-options' is enabled, upon a successful
Proxy-ARP/ND lookup, the PE will perform a 'unicast-forward' action
only if the ARP-Request or NS messages carry unknown options, as
explained in Section 3.2. The 'unicast-forward unknown-options'
configuration allows the support of new applications using ARP/ND in
the BD while still reducing the flooding.
<JMC>
What happens, for these two options, when there is no hit inside “Proxy-ARP/ND
Table”? </JMC>
<snip>
3.5. Flooding (to Remote PEs) Reduction/Suppression
The Proxy-ARP/ND function implicitly helps reducing the flooding of
ARP Request and NS messages to remote PEs in an EVPN network.
However, in certain use-cases, the flooding of ARP/NS/NA messages
(and even the unknown unicast flooding) to remote PEs can be
suppressed completely in an EVPN network.
For instance, in an IXP network, since all the participant CEs are
well known and will not move to a different PE, the IP->MAC entries
may be all provisioned by a management system. Assuming the entries
for the CEs are all provisioned on the local PE, a given Proxy-ARP/ND
table will only contain static and EVPN-learned entries. In this
case, the operator may choose to suppress the flooding of ARP/NS/NA
to remote PEs completely.
<JMC>
Cf. my comment about DAD in section 3.
</JMC>
<snip>
3.6. Duplicate IP Detection
The Proxy-ARP/ND function SHOULD support duplicate IP detection so
that ARP/ND-spoofing attacks or duplicate IPs due to human errors can
be detected.
<JMC>
Duplicate Address Detection is mandatory: s/SHOULD/MUST
IMHO, it would be useful to add text explaining why RFC 6957 doesn’t solve your
issues and so you need to specify a solution “from scratch”. </JMC>
<snip>
5.1. All Dynamic Learning
In this scenario for minimum security and mitigation, EVPN is
deployed in the peering network with the Proxy-ARP/ND function
shutdown. PEs do not intercept ARP/ND requests and flood all
requests, as in a conventional layer-2 network.
<JMC>
ND messages are IP based:
s/layer-2/layer-3
</JMC>
<snip>
6. Security Considerations
<snip>
The solution also provides protection against Denial Of Service
attacks that use ARP/ND-spoofing as a first step. The Duplicate IP
Detection and the use of an AS-MAC as explained in Section 3.6
protects the BD against ARP/ND spoofing.
<JMC>
You are assuming that the attacker and the victim are not on the same L2-Link.
Is it always the case in your scenarios (i.e., only P2P links between PE and
CE)? If not, IMHO, it would better to: - s/protects/mitigates - Add text
explaining when there is a protection and when there is no protection. </JMC>
<JMC>
I would some text about the fact that your proposal cannot/will not work if
there is a (current or future) security mechanism securing ARP/ND exchanges
(e.g., SEND) because the PE is not able to secure "proxied" ND messages (i.e.,
with SEND, the PE is not aware of the security credentials linked to an IP
address). </JMC>
<snip>
Thanks in advance for your replies.
Best regards,
JMC.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
