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

[Eric Rescorla <[e-mail]>]

On Mon, Oct 2, 2017 at 4:54 PM, Donald Eastlake <[e-mail]> wrote:

> Hi Eric,
>
> My apologies for the delay in response. (For part of the time I was on
> a cruise...)
>
> It looks like we are in agreement on most items.
>
> See below.
>
> On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla <[e-mail]> wrote:
> >
> >
> > 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?
>
> We are working on a draft revision to reflect the above thinking to a
> greater extent and decrease sketchiness.
>
> >> > 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?
>
> Well, at some level some elements of your protocol stack are "relying"
> on it or "trusting" it or whatever term you want, but it's trivially
> forged unless you use additional security protocols so I guess we
> could say something about that. TRILL supports different link
> technologies but if you are using an Ethernet link, I suppose you
> could use 802.1AE to improve trust in MAC addresses at layer 2. It
> wouldn't hurt to mention that but it has very little to do with ARP/ND
> optimization or TRILL.
>

I think if you just sort of say "you are using it, but it's not trustworthy
and here's why" you have it covered.

-Ekr


> >> > 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".
>
> OK.
>
> >> >    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.
>
> OK.
>
> >> > 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.
>
> I'll see what we can do.
>
> >> > ------------------------------------------------------------
> ----------
> >> > 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?
> >
> > 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"
>
> OK. We can add some clarifying material to Section 4 before the 4.1
> heading.
>
> >> > 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.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>