Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT)

[Donald Eastlake <[e-mail]>]

Hi Eric,

On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla <[e-mail]> wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-arp-optimization-08: Discuss
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------

As a general comment, the Security Consideration section could use
clarification and some expansion.

Although one can imagine various mixed modes, to the first approximation
there are two ways of doing the optimization of various multi-destination
messages discussed in this document:

   - Using data plane learning by observing ARP/ND and similar messages (in
   addition to the learning of MAC addresses from the data plane which is
   enabled by default in TRILL). As described in this document, such data
   plane learning by TRILL switches can be used to sometimes optimize
   ARP/ND/RARP/unknown-destination messages. But the result isn't particularly
   more or less secure than it is when this data plane learning is done by end
   stations rather than by TRILL switches (or bridges or other kinds of
   switches) in the middle doing some optimization of the relevant
   multi-destination messages. Interface address information learned through
   data plane learning by edge TRILL switches can also be propagated via the
   control plane but this is not significantly different from propagating that
   information via the multi-destination messages that are being optimized to
   unicast or optimized away.
   - Using a complete, trusted directory as might be based on an
   orchestration system in a data center. Since the messages between TRILL
   switches doing ARP/ND/RARP/unknown-destination optimization can be secured
   and the TRILL switches can be configured to ignore data plane learning,
   this enables TRILL switches to provide answers that are "correct" in that
   they correspond to the data in this complete, trusted directory. However,
   there can still be various forged messages/addresses on a local link
   between end station(s) and edge TRILL switches. Such a local link can, with
   TRILL, be a bridged LAN, so such forgeries emitted by an end station may be
   seen by other end stations and cause incorrect learning from the data plane.

The existing Security Considerations section is a bit sketchy and
concentrates more on the data plane case, as that is the one with the
greatest security challenges.

> It's not clear to me how the security properties of this mechanism
> compare to existing TRILL. The text says:
>
>    Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be
>    easily forged. Therefore the learning of MAC/IP addresses by RBridges
>    from ARP/ND should not be considered as reliable. See Section 4.1 for
>    SEND Considerations.
>
> "not considered as reliable" seems suboptimal. You need to cover how
> this mechanism compares to the non-use of this mechanism.

As above, the optimization mechanisms do not make any significant
difference to the inherent insecurities of data plane learning but when
used with a complete, trusted directory, it improves considerably over data
plane learning..

> This document seems very sketchy on what you do when you get duplicate
> IPs.

Why should what you do when you notice a duplicate IP address be
significantly different just because some multi-destination messages are
being optimized? Why shouldn't you just do whatever you do now and why is
that any of TRILL's business?

>    In the case where the former owner replies, a Duplicate Address has
>    been detected. In this case the querying RBridge SHOULD log the
>    duplicate so that the network administrator can take appropriate
>    action.
>
> How does logging solve the problem?

It doesn't but it seems better than not logging.

> What do you reply to ARPs with and/or propagate to other nodes?

If you are asking how you reply to ARPs if the IP address being ARPed for
has been found to be duplicated, there are the two cases outlined above. If
you are using a complete, trusted directory, you give the presumed correct
answer provided by that directory. If you are using data plane learning,
you use whatever you last learned from the data plane (which could have
been a forgery over writing good information or good information over
writing a forgery or a forgery overwriting a different forgery or ...).

> Do you tell the originator of the advertisement you have a duplicate?

As far as I know there is no standardized way to tell a station that you
think it has an IP address that is duplicated locally and I don't think it
is the job of TRILL to provide such a mechanism. Certainly this document
does not propose anything of that sort.

>    When a newly connected end-station exchanges messages with a DHCP
>    [RFC2131] server an edge RBridge should snoop them (mainly the
>    DHCPAck message) and store IP/MAC mapping information in its ARP/ND
>    cache and should also send the information out through the TRILL
>    control plane using ESADI.
>
> What happens if the attacker sets up a fake DHCP server and pretends
> to assign addresses to himself? It seems like maybe that's the same
> as fake ARPs but maybe not.

This snooping on DHCP messages only applies to the data plane learning
case. In the case of a complete, trusted directory, edge RBridges already
know the right answer, so to speak. With data plane learning, if there are
forged DHCP messages, things are likely to get all screwed up. Of course,
you could run DHCP over IPsec but, partly due to the localized nature of
DHCP, I don't think very many people do that. There is also RFC 3118 which
can be used to authenticate DHCP messages, but that assumes the
distribution of keying information.

There isn't much difference between the various multi-destination messages
(ARP / DHCP) advertising the addresses and point of attachment of
interfaces. But, overall, I'm not sure why a document that is just
describing ways to optimize the distribution of various multi-destination
messages needs to analyze the security of the protocols implemented by
those multi-destination when, as in the data plane learning case, it is not
significantly changing that security.

> In general, the security considerations need a complete threat
> analysis per 3552.

I don't think there is that much new in this document. While the Security
Considerations section needs clarification and some expansion, I don't
think it is, for example, the job of this document to do a threat analysis
of the ARP protocol as long as it can make a reasonable case that the
security of ARP is not significantly changed by the optimizations specified.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

For completeness, I've cut and pasted below the COMMENT responses I sent to
you a while ago.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> S 2.
>
>    plane on the edge RBridges, it should be possible to completely
>    suppress flooding of ARP/ND messages in a TRILL Campus, When all end-
>    station MAC addresses are similarly known, it should be possible to
>    suppress unknown unicast flooding by dropping any unknown unicast
>    received at an edge RBridge.
>
> Are these "should be possibles" normative? Descriptive?

Section 2 of this document is a general discussion of the optimization
problem which, while it does mention a couple of possible facets of
potential solutions, is not intended to be normative.


> S 4.
> This is a sequence of steps, so it would be nice to preface them with
> a list of the steps. It's also odd to have SEND considerations right
> in the middle here.

Sorry, I don't understand exactly what you are pointing at as a
sequence of steps. All of Section 4? Just the text between the Section
4 heading and the Section 4.1 heading? Something else?


> 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP
>
> Please explain what a non-zero IP is and why it's relevant.
> This graf also needs an introductory sentence or something before
> the bullets.

Here is a copy of the response that was sent to a similar comment in
Dale Worley's GENART review:

This section is talking about getting and handling the IP/MAC
mapping information for a local end station by an edge RBridge. An
ARP/ND from such a local end station might show a zero source IP
address if the end station does not have one or is probing for
duplicates.

Perhaps the title for the Section should be something like

   4.3 Extracting Local End Station IP/MAC Mapping Information

and a new first paragraph could be added something like

   Edge RBridges extract and use information about the correspondence
between local end station IP and MAC addresses from the ARP/ND
messages those end stations send as described below. An apparent zero
source IP address means that the end station is probing for duplicate
IP addresses and messages with such a zero source IP address are not
used for the extraction of IP/MAC address mapping information.


> S 4.4.
>    It is not essential that all RBridges use the same strategy for which
>    option to select for a particular ARP/ND query. It is up to the
>    implementation.
>
> This seems inconsistent with the MUST in arm (b) below, because I
> can just take some other arm. It's also kind of surprising to be this
> non-prescriptive.

The wording needs to be clarified. Which lettered item listed below
applies is determined by the circumstances; however, which of the
numbered strategies associated with these items is followed is an
implementation choice in handeling any particular ARP/ND.


> S 8.
>    some other location (MAC/VM Mobility) and gets connected to egde-
>
> Nit: edge is mispelled.

OK.