Re: [secdir] SECDIR review of draft-ietf-trill-esadi-07

[Donald Eastlake <[e-mail]>]

Hi Phil,

On Thu, Apr 24, 2014 at 11:52 AM, Phillip Hallam-Baker
<[e-mail]> wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should
> treat these comments just like any other last call comments.
>
> This document is describing extensions to a routing infrastructure.
> As such the only security properties that are reasonably achievable
> without inappropriate assumptions such as trustworthy routing nodes
> is to assure continuity of service. We should assume that
> authentication and confidentiality of the message content are
> assured via some end-to-end means where the ends are the source and
> destination of the messages.

I agree that people should use end-to-end security to protect their
data in transit but that isn't really related to this ESADI document.

It is helpful to have read RFC 6325, the TRILL base protocol
specification, in understanding this document, which is why the ESADI
draft says "familiarity with [RFC6325] is particularly assumed".

I view this ESADI document as providing two things:

(1) A reliable information flooding mechanism that is scoped by data
label (VLAN or fine grained label) such that, in a quiescent network,
all TRILL switches that have advertised interest in a particular label
will end up with the same flooded information state associated with
that label.

(2) A method of using the facility in item (1) above to flood
information on the reachability of end stations by edge TRILL
switches.

Edge TRILL switches need to learn what end station destinations are
reachable from (i.e., connected to) edge TRILL switch in order to
efficiently handle end station traffic. By default they learn from
observation of the data plane. ESADI provide a mechanism whereby such
reachability information for an end station in data label X, however
learned, can be flooded to all TRILL switches that also advertise
interest in data label X and are participating in ESADI for data label
X.

ESADI uses essentially the same mechanisms to authenticate its
reliable flooding mechanism as does IS-IS.

End stations reachability information can be learned through
cryptographically hardened Layer 2 registration methods a couple of
which I give as examples below. This ESADI document does not specify
any such Layer 2 end station registration methods and does not require
their use but suggests that their use could improve security.

> [It would be rather useful if the IAB would draft a document that
> would state what security properties are expected at which level]
>
> ESADI does provide for improved service assurances by allowing the
> authentication of nodes.

End stations can authenticate to an edge TRILL switch if the edge
TRILL switch supports an existing Layer 2 authentication/registration
protocol. Example registration protocols might be Wi-Fi (IEEE 802.11)
association and authentication or IEEE 802.1X port based
authentication, both of which use the IETF EAP (Extensible
Authentication Protocol).

> What is less clear is how this authentication is leveraged Section
> 5.1 suggests that authenticating endpoints permits higher confidence
> to be built up. if end nodes are authenticated to their MAC
> address. But this authentication only has value if there is a chain
> of custody authentication to the relying party. Section 6.2
> describes a mechanism that might be relevant here. A pointer would
> be helpful.

TRILL has a facility for assigning a one byte unsigned integer
confidence level to any particular association of a destination to an
edge TRILL switch from which that destination is reachable.  Section
5.1 mentions that it is reasonable for the network manager to assign a
higher confidence level to such edge TRILL switch end station
reachability information if it was learned through a secured
registration protocol.

I think you meant to refer to Section 6.3 that talks about
authenticating ESADI PDUs, particularly the default authentication if
nothing more specific is configured. That mechanism can be used to
authenticate end station destination reachability information as it is
flooded with ESADI and provides at least some sort of "chain of
custody", as you refer to it, between the originating TRILL switch and
the relying TRILL switch. You say "a pointer would be helpful" but I'm
not sure what pointer you want. We could add a reference to RFC 5310,
"IS-IS Generic Cryptographic Authentication" since, as I say, the
method for authenticating ESADI PDUs is essentially the same as that
used in IS-IS.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> --
> Website: http://hallambaker.com/