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

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-trill-arp-optimization-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.


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

   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? What do you reply to ARPs with
and/or propagate to other nodes? Do you tell the originator of the
advertisement you have a duplicate?


   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.

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

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.


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.


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.


S 8.
   some other location (MAC/VM Mobility) and gets connected to egde-

Nit: edge is mispelled.