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

[Eric Rescorla <[e-mail]>]

On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake <[e-mail]> wrote:

> 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.
>

Yes, this seems like a reasonable assessment. Alia, does someone have the
action item to make it less sketchy?


> 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..
>

That had kind of been my impression, but then I don't understand what "not
considered as reliable" is doing here. I'm supposed to be doing something
with it, so while it may be non-secure, I'm still relying on it, no?



> 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?
>

Because you're getting the information via different vector, TRILL needs to
specify what you do,
if only to say "do what you would do otherwise".

>
>
> >    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.
>

OK.



>    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.
>

Well, in this case, you have a new threat vector: DHCP. Even if it is the
same kind of threats, it's still a new threat vector.
More generally documents need to contain complete security considerations
sections. If the security considerations
are the same as with some other document, then they need to say that.



> > 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.
>

Sure, but it also doesn't make that case.


> ----------------------------------------------------------------------
> > 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] <(508)%20333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA
> <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA&entry=gmail&source=g>
>  [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?
>

Sorry, my point is that if I read this correctly, I do 4.3, then 4.4, etc.
It would be nice if they were listed ahead of this as "this is what you do,
now read the sections"


> > 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
>

LGTM


>
> > 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.
>

OK.

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