Skip to main content

Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol
draft-ietf-trill-esadi-09

Yes

(Ted Lemon)

No Objection

(Alia Atlas)
(Barry Leiba)
(Benoît Claise)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Spencer Dawkins)

Abstain


Note: This ballot was opened for revision 07 and is now closed.

Ted Lemon Former IESG member
Yes
Yes (for -07) Unknown

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2014-06-08) Unknown
Thanks for the work to address my Discuss
Alia Atlas Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2014-05-14 for -07) Unknown
In Section 4.4:
s/EASDI-LSP/ESADI-LSP/

In Normative References section:
"[RFCfgl] - Eastlake, D., M. Zhang, P. Agarwal, R. Perlman, D. Dutt,
         "TRILL (Transparent Interconnection of Lots of Links): Fine-
         Grained Labeling", draft-ietf-trill-fine-labeling, in RFC
         Ediotr's queue."
s/Ediotr's/Editor's/
Barry Leiba Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2014-05-15 for -07) Unknown
I believe Russ' comment below is something that should be handled:

> Section 8, the security considerations, say:
>
> ESADI PDUs can be authenticated through the inclusion of the
> Authentication TLV as described in Section 6.3.
> 
> However, there seems to me something missing.  Section 6.3 tells how to derive a 256-bit authentication
> key.  It does not say how that key will be used to actually compute a message authentication code.  I would
> expect a reference to this information to be included in Section 6.3.
Joel Jaeggli Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2014-05-15 for -07) Unknown
I support Stephen's discuss on privacy concerns and the need to elaborate on them.

For the privacy concerns, having some experience on campus networks, it can be really helpful to pin point where an end node is when it is acting up (during a security incident).  So there are clear advantages of having this tie to authenticated connections for the ESADI method as well as the ability to blackhole infected hosts.  For privacy considerations, ESADI also tracks when end nodes move around, which should be mentioned as a consideration (good for security for blackholing and tied to NAC for network hygiene).  

If this information (location of end node) is logged, (basically - as I read it) the full network map could be logged and created, as well as maintained over time as it changes.  On a campus network, privacy issues may arise when some sort of investigation is looking to identify where someone was at a particular point in time (or who did something).  This has pros and cons.  With other services (web logs in particular), some university admins have had the practice of removing logs after 30 days (by policy) to protect privacy and to avoid dealing with warrants - essentially if they don't have the data, they can't help.  An example of that is web logs and dealing with the illegal download of media.  Now we should not get into that full explanation of this example to explain the privacy issues, but a description of the risks to privacy when location over time could be pin pointed would be helpful for implementers to understand if they decide log and aggregate this information.  They will want to consider appropriate storage periods.  If it is stored at all, they could get subjected to record retention requirements as well (but I have not looked to see if any apply, I'm just highlighting that there could be requirements once they have and log this data).

I also support Russ' request from the Gen-art review and agree with the proposed solution.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2014-06-13) Unknown
Thanks for adding the privacy considerations text.
Brian Haberman Former IESG member
Abstain
Abstain (2014-05-15 for -07) Unknown
I support Adrian's and Stephen's DISCUSS points.  It is incredibly disconcerting that there is no interoperability discussions in this document despite the claims in section 1.1.