Re: [trill] Alissa Cooper's Discuss on draft-ietf-trill-smart-endnodes-10: (withDISCUSS and COMMENT)

[Donald Eastlake]

Hi Alissa,

A -11 version of draft-ietf-trill-smart-endnodes has been uploaded
with the intent of resolving your discuss. Please look at it and see
if you can clear.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Wed, Mar 7, 2018 at 2:35 PM, Donald Eastlake  wrote:
> On Wed, Mar 7, 2018 at 10:01 AM, Alissa Cooper  wrote:
>> Hi Fangwei,
>>
>> As I noted in response to the Gen-ART reviewer, I managed to ballot before
>> reading the rest of this thread (sorry!), but I still think the diagram in
>> 4.3 is confusing and not consistent with the text. To my eye row 3 shows
>> two
>> bytes’ worth of fields but the label says “4 bytes.” RSV is depicted as 2
>> bits but the text says it is 6 bits. The combination of these two
>> inconsistencies makes it hard to know what the actual lengths are supposed
>> to be.
>
> I agree that the figure is a little confusing. I suggest the following:
>
> +-+-+-+-+-+-+-+-+
> |Type=Smart-MAC |  (1 byte)
> +-+-+-+-+-+-+-+-+
> |   Length  |  (1 byte)
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+
> |F|M|  RSV  |  VLAN/FGL Data Label |  (4 bytes)
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  MAC (1)(6 bytes)|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  .   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  MAC (N)(6 bytes)|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
>
>> Alissa
>>
>> On Mar 7, 2018, at 12:55 AM, hu.fang...@zte.com.cn wrote:
>>
>> Hi，Alissa Cooper
>>
>> Thanks for your review and comments.
>>
>> The new version(version 10)  has updated to fix your comments.
>>
>> The format of Smart-MAC APP sub-TLV and the text  has been changed to the
>> following:
>>
>> The length of F,M,RSV,VLAN/FGL data Label is 4 bytes. and the length of
>> VLAN/FGL Data Label field is 24 bits.
>>
>>
>>+-+-+-+-+-+-+-+-+
>> |Type=Smart-MAC |  (1 byte)
>> +-+-+-+-+-+-+-+-+
>> |   Length  |  (1 byte)
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |F|M|RSV|  VLAN/FGL Data Label  |  (4 bytes)
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |  MAC (1)   (6 bytes) |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |  .   |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |  MAC (N)   (6 bytes) |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>  Figure 3 Smart-MAC APPsub-TLV
>>
>>
>>o  VLAN/FGL Data Label: 24bits.  If F is 1, this field is a 24-bit
>>   FGL Data Label for all subsequent MAC addresses in this APPsub-
>>   TLV.  Otherwise, if F is 0, the lower 12 bits is the VLAN of all
>>   subsequent MAC addresses in this APPsub-TLV, and the upper 12 bits
>>   is not used(sent as zero and ignored on receipt).  If there is no
>>   VLAN/FGL data label specified, the VLAN/FGL Data Label is zero.
>>
>>
>>
>>
>> Regards.
>>
>> Fangwei.
>>
>> 原始邮件
>> 发件人：AlissaCooper 
>> 收件人：The IESG 
>> 抄送人：draft-ietf-trill-smart-endno...@ietf.org
>> trill-cha...@ietf.org
>> sha...@ndzh.com trill@ietf.org
>> 
>> 日 期 ：2018年03月07日 04:45
>> 主 题 ：Alissa Cooper's Discuss on draft-ietf-trill-smart-endnodes-10:
>> (withDISCUSS and COMMENT)
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-trill-smart-endnodes-10: 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-smart-endnodes/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> This should hopefully be easy to fix and was pointed out by the 

Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-smart-endnodes-10: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Eric,

A -11 version of draft-ietf-trill-smart-endnodes has been uploaded
with the intent of resolving your Discuss. Please look at it and see
if you can clear.\

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com


On Sat, Mar 10, 2018 at 9:22 PM, Donald Eastlake  wrote:
> Hi Eric,
>
> On Thu, Mar 8, 2018 at 8:44 AM, Eric Rescorla  wrote:
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-trill-smart-endnodes-10: Discuss
>>
>> ...
>>
>> --
>> DISCUSS:
>> --
>>
>> Review in context at: https://mozphab-ietf.devsvcdev.mozaws.net/D3548
>>
>>Smart Endnodes would not bring more security and vulnerability issues
>>than the TRILL ES-IS security defined in [RFC8171].
>>
>> IMPORTANT: I think you need to discuss the security implications of
>> checking and/or not checking the smart endnodes MAC address (a MAY in
>> S 5.2). My understanding is that TRILL is kind of wishy-washy on MAC
>> spoofing in general, but if you *do* have some sort of MAC enforcement
>> in place but you don't enforce here, then this obviously bypasses
>> that. Similar comments apply to the SmartHello filtering, I think.
>
> OK on data.
>
> Smart Hellos are a very different thing. They are TRILL ES-IS PDUs
> always sent to the TRILL-ES-IS multicast Ethernet address (see
> Sections 5 and 7.6 of RFC 8171). The source MAC address of such PDUs
> is an important protocol field that is made available to the code
> processing the PDU. The first Smart Hello received from an End Station
> would be from an unknown MAC until adjacency is established, unless
> that MAC address was specially configured or something, even if that
> end station is a valid Smart Endnode. You might want an RBridge port
> to drop all Ethernet frames that are not from white-listed MACs or
> something, but that sort of general Ethernet port security feature
> isn't properly part of TRILL.
>
> Since connections from end stations to edge RBridge ports are
> Ethernet, such ports can always require end stations to authenticate
> themselves with [802.1X} and encrypt and authenticate traffic between
> the end station and the edge RBridge port with [802.1AE] (MACSEC) as
> discussed in the base TRILL protocol specification draft [RFC6325].
> This seems more powerful than just checking a MAC address although you
> could always do both.
>
> I'm not sure it should be necessary for every TRILL draft the
> optionally further empowers an end station to have to go into all
> these layer 2 security options given that MACSEC is mentioned in the
> base TRILL protocol specification that is referenced.
>
>>Smart-Hellos can be secured by using Authentication TLVs based on
>>[RFC5310].
>>
>> I concur with Ben that you should explain the consequences of doing this or 
>> not.
>
> OK, although I don't think there is much to say other than that
> checking such authentication stops rogue end nodes not in possession
> of the required keying material from being recognized as a valid smart
> end node.
>
>> --
>> COMMENT:
>> --
>>
>>
>> If SE1 wishes to correspond with destination MAC D, and no endnode
>>entry exists, SE1 will encapsulate the packet as an unknown
>>
>> Should D be shown on the diagram below? I don't see it.
>
> Yeah, probably the network connection to Endnode1 should be labelled D.
>
>>   the same meaning as the Holding Time field in IS-IS Hellos [IS-IS]
>>   . A Smart Endnode and an Edge RBridge supporting Smart Endnodes
>>   MUST send a Smart-Hello at least three times during their Holding
>>
>> Ooh, bad break here at this period.
>
> OK.
>
>>o  MAC(i): This is a 48-bit MAC address reachable in the Data Label
>>   given from the Smart Endnode that is announcing this APPsub-TLV.
>>
>> does "given from" mean something different than "sent by"?
>
> No. "sent by" would be more usual wording.
>
>>o  When SE1 wishes to send a multi-destination (multicast, unknown
>>   unicast, or broadcast) to the TRILL campus, SE1 encapsulates the
>>   packet using one of the trees that RB1 has specified.
>>
>> I see this called "BUM" in other documents. This is a nit, but do you
>> want to use consistent terminology?
>
> I think too many documents overuse acronyms. If this draft wants to
> list out the sub-types or use "multi-destination" instead of the
> acronym, I think that's good.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com

___
trill mailing list

Re: [trill] Alvaro Retana's No Objection on draft-ietf-trill-multilevel-unique-nickname-06: (with COMMENT)

[Donald Eastlake]

Hi Alvaro,

On Tue, Mar 6, 2018 at 12:37 PM, Alvaro Retana  wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-multilevel-unique-nickname-06: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> (1) The nickname selection process for multilevel is not backwards compatible
> because of the use of the NickBlockFlags APPsub-TLV.  That is ok since the
> border RBridges can recognize "old" Rbridges (ones that don't support this
> specification) in an area. A couple of related comments:
>
> (1.1) Section 4.4. (Capability Indication) says that "Non border RBridges in 
> an
> area SHOULD understand the NickBlockFlags APPsub-TLV."  That statement is
> somewhat contradictory (maybe that's not the right word, but the only one that
> comes to mind):
>
> - On one hand, non border RBridges could be just be "old" (ones that don't
> support this specification).  We can't normatively specify something that by
> definition nodes that don't support this specification won't know about.
>
> - On the other hand, if the non border Rbridge does support this 
> specficiation,
> then why wouldn't it understand the NickBlockFlags APPsub-TLV?  IOW, why isn't
> the "SHOULD" a "MUST" instead?  When is it ok to not do it?
>
> All this is to say that I think that "SHOULD" should not be used normatively.
> s/SHOULD/should

Sounds reasonable to me.

> (1.2) Given that rfc6325 specifies a single Level 1 network, it is reasonable
> to expect that networks implementing these multilevel extensions will grow 
> from
> a single area to multiple.  It would be ideal to include Deployment
> Considerations to discuss what a Migration Path would look like.
>
> (2) Maybe I missed it somewhere...  The Security Considerations section says
> that "border RBridges need to fabricate the nickname announcements...Malicious
> devices may also fake the NickBlockFlags APPsub-TLV to announce a range of
> nicknames."  I'm sure that malicious devices don't only include ones that are
> unauthenticated, but may include over or under claiming by existing border
> RBridges or even non border RBridges originating the NickBlockFlags 
> APPsub-TLV.
>
> (2.1) Is the origination of the NickBlockFlags APPsub-TLV restricted to border
> RBridges?  If so, why isn't there a check to make sure that the NickBlockFlags
> APPsub-TLV came from a border RBridge?

Such a check would add some complexity and it is not clear there would
be much gain as an RBridge that is forging NickBlockFlags APPsub-TLVs
would presumably just falsely claim it is a border RBridge by claiming
ownership of at least one Level 2 nickname.

> (2.2) rfc8243 talks about the (potential) ability of border RBridges to
> "discover each other...by using the IS-IS "attached bit" [IS-IS] or by
> explicitly advertising in their LSP "I am a border RBridge".  But I didn't see
> these options/mechanisms mentioned in this document.

Border RBridges know they are border RBridges because, by
configuration, they are talking to both Level 1 and 2. They act
specially but it is not clear what good looking at the attached bit or
border RBridges advertising that explicitly in the LSP would do. If
you are in Level 2 and see some Level 2 RBridge advertising that it
owns Level 1 nicknames, you know it is a border RBridge and likewise,
if you are in Level 1 and see some Level 1 RBridge advetising that it
owns Level 2 nicknames, you know it is a border RBridge. And the
nicknames are distinguished by being taken from mutually exclusive
ranges of nicknames.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill