Re: [trill] ESADI draft change suggestion

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, zhai.hongjun@zte.com.cn wrote:
>
> 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: zhai.hongjun@zte.com.cn
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
>
>
>
>
> *Sujay Gupta <sujay.ietf@gmail.com>*
> 发件人: trill-bounces@ietf.org
>
> 2012-07-23 09:34
>
> 	
> 收件人
> 	trill@ietf.org
> 抄送
> 	
> 主题
> 	[trill] ESADI draft change suggestion
>
>
>
> 	
>
>
>
>
>
> 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.
>
> [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
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>