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

[Eric Rescorla <[e-mail]>]

Thanks for reminding me. I had indeed forgotten.

On Thu, Oct 26, 2017 at 10:55 AM, Donald Eastlake <[e-mail]> wrote:

> Hi Eric,
>
> I realize that most of the delay has been on the TRILL WG end but I hope
> you don't mind if I ping you again on looking at the -09 revision of this
> draft...
>
> 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]
>
> On Mon, Oct 9, 2017 at 7:05 PM, Donald Eastlake <[e-mail]> wrote:
>
>> Hi Eric,
>>
>> A -09 version of draft-ietf-trill-arp-optimization has been posted.
>> Could you look at it to see if it resolves your comments?
>>
>> 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]
>>
>> On Mon, Oct 2, 2017 at 2:12 PM, Eric Rescorla <[e-mail]> wrote:
>>
>>>
>>>
>>> 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
>>>> <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"
>>>>
>>>> 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
>>>> <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA&entry=gmail&source=g>
>>>>  [e-mail]
>>>>
>>>
>>>
>>
>