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

From: Eric Rescorla <[email-masked]>
Date: Wed, 05 Jul 2017 04:38:54 -0700

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.

This document seems very sketchy on what you do when you get duplicate
IPs.

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

   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.

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 6 Jul 2017 06:06:57 -0400

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:[email-masked]] 

Sent: Wednesday, July 5, 2017 7:39 AM

To: The IESG

Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]

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

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

 

 

DISCUSS:

> It's not clear to me how the security properties of this mechanism compare to existing TRILL. The text says:

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

> This document seems very sketchy on what you do when you get duplicate IPs.

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

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

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

COMMENT:

S 2.

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.

   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.

Nit: edge is mispelled.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Jul 2017 06:06:23 -0700

On Thu, Jul 6, 2017 at 3:06 AM, Susan Hares <[email-masked]> 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
>
>
>
> From: Eric Rescorla [mailto:[email-masked] <[email-masked]>]
>
> 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?

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

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

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

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 6 Jul 2017 16:00:01 -0400

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? 

Sue  

From: Eric Rescorla [mailto:[email-masked]] 
Sent: Thursday, July 6, 2017 9:06 AM
To: Susan Hares
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT)

Eric: 

Sue Hares

-----Original Message-----

To: The IESG

 

 

 

DISCUSS:

Sorry, no. I'm saying that "not be considered reliable" is not operationalizable by

reliable? More specifically, what is their security posture if they use the mechanism

This seems like it's of limited use if this actually is an attack. My experience

they see a lot of errors. I've certainly seen duplicate IPs in small networks

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

 

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.

S 4.

 

 

S 4.4.

   implementation.

 

S 8.

Nit: edge is mispelled.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Jul 2017 13:51:21 -0700

On Thu, Jul 6, 2017 at 1:00 PM, Susan Hares <[email-masked]> 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:[email-masked]]
> *Sent:* Thursday, July 6, 2017 9:06 AM
> *To:* Susan Hares
> *Cc:* The IESG; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08:
> (with DISCUSS and COMMENT)
>
>
>
>
>
>
>