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 1:00 PM, Susan Hares <[e-mail]> wrote:

> Eric:
>
>
>
> Thank you for your answers.   I will investigate the issues further and
> work with the authors to suggest some text.  May I or the authors follow up
> with additional questions?
>

Please. Let me know if I can help, elaborate, etc.

-Ekr


>
>
> Sue
>
>
>
> *From:* Eric Rescorla [mailto:[e-mail]]
> *Sent:* Thursday, July 6, 2017 9:06 AM
> *To:* Susan Hares
> *Cc:* The IESG; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Subject:* Re: Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08:
> (with DISCUSS and COMMENT)
>
>
>
>
>
>
>
> 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.
>
>
>
>
>
>
>