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

[Eric Rescorla <[e-mail]>]

On Thu, Jul 6, 2017 at 3:06 AM, Susan Hares <[e-mail]> wrote:

> Eric:
>
>
>
> Thank you for your comments and questions.  The text of this email
> requests clarification on your discuss so that I may aid the authors in
> adjusting the draft.   I have included my question inline below.
>
>
>
> Sue Hares
>
>
>
> -----Original Message-----
>
> From: Eric Rescorla [mailto:[e-mail] <[e-mail]>]
>
> Sent: Wednesday, July 5, 2017 7:39 AM
>
> To: The IESG
>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
>
> Subject: Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08:
> (with DISCUSS and COMMENT)
>
>
>
> 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.
>
>
>
> Question 1:  Are you asking how the "ARP/ND" is unreliable?  Is this not
> documented adequately in the SEND documentation?
>
> Are you asking why the learning of MAC/IP addresses by the RBRIDGE using
> ARP/ND is not reliable in addition to the issues raised by the SEND
> document?
>
Sorry, no. I'm saying that "not be considered reliable" is not
operationalizable by
the implementor. What are they supposed to do with information which is not
reliable? More specifically, what is their security posture if they use the
mechanism
documented in this document versus if they do not?


> > How does logging solve the problem?
>
> Question 2: Logging allows the network management systems to detect the
> problem, and determine if SEND should be used or if other security measures
> should be taken.  Are you looking for other mechanisms outside of SEND?
>

This seems like it's of limited use if this actually is an attack. My
experience
with logging systems is that people don't check their logs very often unless
they see a lot of errors. I've certainly seen duplicate IPs in small
networks
plenty of times, and I just ignore them. I assume others do as well.


> > 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?
>
>
>
> Question 3: Are you specifically asking about the reply to duplicate
> address detection ARPs in the first question?  Are you looking for a
> specific answer to second part of this question.  In my understanding of
> security (which is limited compared to yours), I would not recommend
> responding to the originator of the advertisement that there is a duplicate
> since this might aid attacks on the valid originator.
>
> Can you provide additional input on what you'd like to see here?
>
I think the spec should take a position on how the implementation should
behave when
it encounters this situation. My general concern here is that you have a
mechanism
which has a known security vulnerability but the spec is pretty silent on
how you should
handle it when you have signs that it is being exploited.


>
>
>
>
> > 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.
>
>
>
> Question 4: Can you provide someone from the SEC-DIR to provide a review
> for a threat analysis per RFC3552.
>
It's probably easier if I review it. If you're looking for a collaborator,
let me know and I'll see who I can round up.

-Ekr


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