Subject: [trill] Draft TRILL Agenda for Vancouver

From: Donald Eastlake <[email-masked]>
Date: Sat, 21 Jul 2012 23:32:55 -0400

Hi,

A draft agenda for the TRILL WG meeting at the upcoming IETF meeting
in Vancouver has been uploaded to the meeting materials site.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Sujay Gupta <[email-masked]>
Date: Mon, 23 Jul 2012 07:04:01 +0530

Hi,

1)

The ESADI protocol objectives as stated in the draft-04, IMO needs added 
statements.
Section 1: "Introduction"

The ESADI
    protocol's potential advantages over data plane learning include the
    following:

    1. Security advantages:..
    2. Fast update advantages:..
<<

w.r.t to Security advantages, albeit ESADI can make a authenticated entries an insecure ESADI increases
the security vulnerability then without it. My recommendation is to recommend a SHOULD clause to implement
security features. A secured deployment of TRILL may choose to live with a unsecured ESADI ( & therefore
possibly a more efficient/lighter ESADI); whilst a TRILL plane bridging 3rd party aggregation and application
layers may choose for trusted/secured model.

2)

This is w.r.t to learning of ESADI entries and timing them out. As per RFC 6325, the entries are expected
to be removed only by the originating RBridge.
Section 4.8.3
"The situation is different for end-station address information acquired via the TRILL ESADI protocol.
It is up to the originating RBridge to decide when to remove such information from its ESADI LSPs
(or up to ESADI protocol timeouts if the originating RBridge becomes inaccessible)."
<<
  For robust behavior it would be better to timeout the entries without depending on ESADI, the reason
is a (wrong)ESADI directed forwarding can cause persistent traffic loss, unlike a best effort flood everywhere
situation. Therefore my recommendation is the specs should not 'mandate' the timing out behavior.

Best Regards,
-Sujay

---

From: [email-masked]
Date: Wed, 25 Jul 2012 14:55:15 +0800

Hi Sujay，

Sorry for delaying reponse. Thanks for the suggestion, please see in-line.

Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: [email-masked]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

Sujay Gupta <[email-masked]> 
发件人:  [email-masked]
2012-07-23 09:34

收件人
[email-masked]
抄送

主题
[trill] ESADI draft change suggestion

Hi,

1)

The ESADI

w.r.t to Security advantages, albeit ESADI can make a authenticated 
entries an insecure ESADI increases
the security vulnerability then without it. My recommendation is to 
recommend a SHOULD clause to implement
security features. A secured deployment of TRILL may choose to live with a 
unsecured ESADI ( & therefore
possibly a more efficient/lighter ESADI); whilst a TRILL plane bridging 
3rd party aggregation and application
layers may choose for trusted/secured model.

[Hongjun] Although security is one of ESADI's potential advantanges, but 
it is not a focal point in that draft. ESADI draft focuses on the general 
mechanism of ESADI protocol, then an ESADI instance can find its 
neighbors, exchange end station addresses and keep link state database 
synchronization with its neighbors. How an ESADI obtains its security 
features is out of the scope of that spec. Since there will be much work 
to do if we consider the security features, I think it is more suitable to 
discuss those features in a new draft than that spec. Therefore, I do not 
think such a "SHOULD clause" is suitable in that spec.

2)
This is w.r.t to learning of ESADI entries and timing them out. As per RFC 
6325, the entries are expected
to be removed only by the originating RBridge.
Section 4.8.3
“The situation is different for end-station address information acquired 
via the TRILL ESADI protocol. 
It is up to the originating RBridge to decide when to remove such 
information from its ESADI LSPs 
(or up to ESADI protocol timeouts if the originating RBridge becomes 
inaccessible).”
<<
 For robust behavior it would be better to timeout the entries without 
depending on ESADI, the reason 
is a (wrong)ESADI directed forwarding can cause persistent traffic loss, 
unlike a best effort flood everywhere 
situation. Therefore my recommendation is the specs should not 'mandate' 
the timing out behavior.

[Hongjun] The spec gives two most common conditions under which an ESADI 
to time out some MAC addresses learned via ESADI (i.e., being told to do 
so by the originating RBridge or finding the originating RBridge 
inaccessible). But it does not mandate or imply that an ESADI can forget 
the learned MACs via ESADI only under the two conditions. Besides the two 
conditions, an ESADI can also decide to forget some learned MACs via ESADI 
based on local configured polices, for example, configured by 
administrator not to learn MACs from a specific ESADI RBridge.

Best Regards,
-Sujay

_______________________________________________
trill mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: Sujay Gupta <[email-masked]>
Date: Wed, 25 Jul 2012 15:49:37 +0530

Hi,

Thanks for the response.

1.) The unsecured ESADI's, potential security issue, could be documented
in the "Security Considerations" section.
2.) The ESADI learned entry behavior,I agree with you explanation;
however the base RFC 6325 is not exactly worded so.
I would recommend if the correction can be added in the next RFC update
or clear-correct changes.
"

   For end-station address information locally learned from frames
   received, the time out from the last time a native frame was received
   or decapsulated with the information conforms to the recommendations
   of [802.1D <http://tools.ietf.org/html/rfc6325#ref-802.1D>].  It is referred to as the "Ageing Time" and is
   configurable per RBridge with a range of from 10 seconds to 1,000,000
   seconds and a default value of 300 seconds.

   The situation is different for end-station address information
   acquired via the TRILL ESADI protocol.  It is up to the originating
   RBridge to decide when to remove such information from its ESADI LSPs
   (or up to ESADI protocol timeouts if the originating RBridge becomes
   inaccessible).

"

Best Regards,
-Sujay

On 25-07-2012 12:25, [email-masked] wrote:
> *Sujay Gupta <[email-masked]>*
> The ESADI protocol objectives as stated in the draft-04, IMO needs
> added statements.
> possibly a more efficient/lighter ESADI); whilst a TRILL plane
> bridging 3rd party aggregation and application
> [Hongjun] Although security is one of ESADI's potential advantanges,
> but it is not a focal point in that draft. ESADI draft focuses on the
> general mechanism of ESADI protocol, then an ESADI instance can find
> its neighbors, exchange end station addresses and keep link state
> database synchronization with its neighbors. How an ESADI obtains its
> security features is out of the scope of that spec. Since there will
> be much work to do if we consider the security features, I think it is
> more suitable to discuss those features in a new draft than that spec.
> Therefore, I do not think such a "SHOULD clause" is suitable in that spec.
>
> 2)
> “The situation is different for end-station address information
> acquired via the TRILL ESADI protocol.
> is a (wrong)ESADI directed forwarding can cause persistent traffic
> loss, unlike a best effort flood everywhere
> [Hongjun] The spec gives two most common conditions under which an
> ESADI to time out some MAC addresses learned via ESADI (i.e., being
> told to do so by the originating RBridge or finding the originating
> RBridge inaccessible). But it does not mandate or imply that an ESADI
> can forget the learned MACs via ESADI only under the two conditions.
> Besides the two conditions, an ESADI can also decide to forget some
> learned MACs via ESADI based on local configured polices, for example,
> configured by administrator not to learn MACs from a specific ESADI
> RBridge.
>
>
> Best Regards,
> -Sujay
>
>
>
>
>
>

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 27 Jul 2012 11:23:40 -0400

Hi,

> the security vulnerability then without it. My recommendation is to

I don't see why that would be true. If you are just learning from the
data plane, a forged multi-destination broadcast frame, either native
or TRILL Data, can cause bad MAC learning entries pretty easily
throughout the VLAN of the frame. Even an insecure ESADI is a little
better. To forge an ESADI frame that would be accepted, an adversary
would have to participate in the ESADI instance, create an acceptable
ESADI-LSP, make sure it didn't get back to the claimed originator so
the claimed originator does not send out a new one with incremented
sequence number to overwrite the forged ESADI information, etc. Of
course, I'm not claiming that "insecure ESADI" is secure; I'm just
saying it seems to me to be a little harder for an adversary to cause
bad MAC learning with ESADI than with data plane learning.

> security features. A secured deployment of TRILL may choose to live with a

Given that, as far as I can recall, there is no "SHOULD" in TRILL to
use any IS-IS authentication, although it is mentioned as a facility
available as a countermeasure against some threats, I don't see how it
makes sense to just put in a "SHOULD" for ESADI authentication. On the
other hand, it might make sense to say that if IS-IS authentication is
in use for IS-IS LSPs, then the default would be to use authentication
for ESADI. This would be similar to the provisions in the BFD over
TRILL draft.

> “The situation is different for end-station address information acquired via
> the TRILL ESADI protocol.

That's not how link state works. In general, you have to retain the
link state information from a remote router until you get an update or
until that remote router leaves the topology. And in the later case,
you still generally want to keep it around for a while (but not
actually use it) to minimize the effort to get the link state
synchronized if the remote router re-joins the topology.

Assume, for example, you have disabled data plane learning and are
depending on ESADI. How does it make any sense to "timeout" ESADI data
from a remote RBridge and suddenly have to send as unknown location
unicast the frames destined for MAC addresses attached to that remote
RBridge, which you had been informed about through ESADI?

Perhaps the wording could be clarified, but I don't see how it makes
any sense to "timeout" ESADI state from a remove RBridge as long as
that RBridge is still reachable and participating in ESADI, etc. And I
don't see how it makes any sense, assuming you are retaining the ESADI
state from such a remote RBridge, to "timeout" making use of that
state.

Thanks,
Donald