[trill] Genart telechat review of draft-ietf-trill-over-ip-15

[Matthew Miller]

Reviewer: Matthew Miller
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-trill-over-ip-15
Reviewer: Matthew A. Miller
Review Date: 2018-03-07
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-03-08

Summary:  Ready with nits

Major issues: NONE

Minor issues: NONE

Nits/editorial comments:

* In Section 4.5. "TRILL Over IP Transport IS-IS SubNetwork Point
of Attachment", the word "of" between ""

"""
The Hellos transmitted out [of] a port indicate what neighbor ports
that port can see on the link by listing what IS-IS refers to as the
neighbor port's SubNetwork Point of Attachment (SNPA)
"""

* In Section 5.2. "Encapsulation Agreement", the first sentence is
difficult to understand; I think it is missing the word "on" between
"sent out" and "a TRILL over IP":

"""
TRILL Hellos sent out [on] a TRILL over IP transport port indicate the
encapsulations for which that port is offering full support through a
mechanism initially specified in [RFC7178] and [RFC7176] that is
hereby extended.
"""

* In Section 5.4. "Native Encapsulation", the word "he" should be
"the" in the sentence "Where he UDP Header is as follows".

* In Section 5.6.1. "TCP Connection Establishment", the word
"connections" should be singular (or the leading "a" dropped) in the
fragment "try to establish a TCP connections to each of them".

* In Section 5.6.1. "TCP Connection Establishment", the occurrence of
"P!" should be changed to "P1".

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

Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-directory-assisted-encap-10: (with COMMENT)

[Donald Eastlake]

Hi Eric,

On Wed, Mar 7, 2018 at 11:41 PM, Eric Rescorla  wrote:
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-directory-assisted-encap-10: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> I support Alvaro's DISCUSS and Kathleen's comment
>
> I also think it would be useful to emphasize the need for some security on the
> links between the egress and ingress nodes, although presumably that's a
> standard TRILL consideration.

Sure. The links between TRILL nodes can be a variety of technologies.
So security on on the links depends on the link technology and is
discussed in the RFC covering TRILL over that link technology.

> Finally
>   nodes. Such spoofing cannot cause looping traffic because TRILL has a
>  hop count in the TRILL header [RFC6325] so that, should there be a
>   loop, a TRILL packet caught in that loop (i.e., an encapsulated
>   frame) will be discarded.
>
> Is it in fact the case that it cannot cause looping or merely that the loop is
> contained by the hop count? Perhaps this is just a terminology issue and in
> routing loop just means infinite loop?

Should probably say "...persistently looping traffic...".

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

[trill] Benjamin Kaduk's practice ballot (No Objection) on draft-ietf-trill-smart-endnodes-10: (with COMMENT)

[Benjamin Kaduk]

[incoming AD ramping up on document reviews; please treat as No
Objection with COMMENT]


I'm confused at what exactly constitutes a "Smart-Hello" -- Section
4.1 says that it "is a type of TRILL ES-IS PDU, which is specified
in [RFC8171]".  The reference does not use the term, so I assume
that the reference is just for ES-IS PDUs.  So, reading on, the
payload consists of TRILL IS-IS TLVs.  Quoting judiciously:
   [...] Both types of Smart-Hellos MUST include a
   Smart-Parameters APPsub-TLV as follows inside a TRILL GENINFO TLV:
[...]
   [...] If
   no Smart Parameters APPsub-TLV appears in a Smart-Hello, that Smart-
   Hello is ignored.

The first makes me think that the presence of Smart-Parameters makes
a Smart-Hello, but he second implies that a Smart-Hello can exist
without one (even if it would always be ignored).


If just the presence of a particular Smart-foo implies that an
entire TRILL GENINFO is a Smart-Hello, then I'm concerned about the
reuse of existing TLVs for subtly different purposes, like the
Neighbor TLV becoming the "Smart Endnode neighbor list"?  This could
be problematic for implementations that do not support Smart-Hello
messages, which would then misinterpret the Neighbor TLV, etc.


I'm also a little unclear on the story for authentication and
protection against the injection of bogus messages.  The
Authentication TLV can be used for the Smart-Hellos, which is good
(but why is it not required?), and I suppose I can't complain
terribly hard about the security model of "if you're authorized to
send, you're authorized to send anything" which is to large extent
universally deployed.  But, we only say that the Edge RBrige "MAY
filter the encapsulation frame based on the inner source MAC and
Data Label as specified for the Smart Endnode." -- why can this not
be a MUST, to prevent spoofing/injection?   In a similar vein,
stronger conditions could be imposed if hybrid ports are disallowed,
but I don't know how feasible that is (or what actual hybrid port
deployments look like).


In Section 5.2:

   The attached edge RBridge processes and forwards TRILL Data packets
   based on the endnode property rather than for encapsulation and
   forwarding the native frames the same way as the traditional
   RBridges.

This left me confused for quite some time.  Is the "for
encapsulation" supposed to be "by encapsulating"?

   o  If receiving a unicast TRILL Data packet with RB1's nickname as
  egress from the TRILL campus, and the destination MAC address in
  the enclosed packet is a MAC address that has been listed by a
  "Smart Endnode", RB1 leaves the packet encapsulated to that Smart
  Endnode.  The outer Ethernet destination MAC is the destination
  Smart Endnode's MAC address, the inner destination MAC address is
  either the Smart Endnode's MAC address or some other MAC address
  that the Smart Endnode advertised in its Smart Hello, and the
  outer Ethernet source MAC address is the RB1's port MAC address.

This is describing modifications that RB1 makes to the received
Ethernet frame containing and encapsulated TRILL Data packet, right?
It might be more clear to describe this as a transformation than a
declarative statement about the nature of the Ethernet frame.
Perhaps

NEW:
   o  If receiving a unicast TRILL Data packet with RB1's nickname as
  egress from the TRILL campus, and the destination MAC address in
  the enclosed packet is a MAC address that has been listed by a
  "Smart Endnode", RB1 leaves the packet in an encapsulated
  form, targetted to that Smart Endnode.  It changes the outer
  Ethernet destination MAC to the destination Smart Endnode's
  MAC address, the inner destination MAC address remains as
  either the Smart Endnode's MAC address or some other MAC
  address that the Smart Endnode advertised in its Smart Hello,
  and the outer Ethernet source MAC address used for the last
  hop is the RB1's port MAC address.


In Section 6

   [...] The
   solution for the MAC flip-flopping issue is to set a multi- homing
   bit in the RSV field of the TRILL data packet.

I think this is supposed to be the 'M' bit that is allocated in the
Smart-MAC APPsub-TLV?

   [...] (An alternative solution
   would be to use the ESADI protocol to distribute multiple attachments
   of a MAC address of a multi-homing group, The ESADI is deployed among
   the edge RBridges (See section 5.3 of [RFC7357])).

This seems like a teaser of an aside that seems like it should either get
expounded upon, for example with a comparison against using the M
bit as previously described, or removed.

-Benjamin

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

Re: [trill] [Gen-art] Genart telechat review of draft-ietf-trill-transport-over-mpls-07

[Alissa Cooper]

Stewart, thanks for your review. I entered a No Objection ballot.

Alissa

> On Mar 2, 2018, at 3:25 PM, Stewart Bryant  wrote:
> 
> Reviewer: Stewart Bryant
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-trill-transport-over-mpls-07
> Reviewer: Stewart Bryant
> Review Date: 2018-03-02
> IETF LC End Date: 2018-03-06
> IESG Telechat date: 2018-03-08
> 
> Summary: An understandable document. The only comment of note is the 
> conflation
> of PW headers and MPLS headers. There are a couple of easy to fix nits.
> 
> Major issues: None
> 
> Minor issues:
> 
> 6. Packet Processing Between Pseudowires
> 
> In this section you conflate PW headers and MPLS headers.
> The PW label is a type of  MPLS label, although it has its own forwarding
> instruction, but the control word is not part of MPLS.
> 
> Nits/editorial comments:
> 
> There is an ASCII art error in Fig 1 on the line containing Tenant1 Site1
> 
> The terms PE device and PE router seem to be used interchangeably.  Is this an
> error, or are they distinct devices.
> 
> The VTSD must be capable of forming TRILL adjacency with the
> SB> Should be "forming a TRILL adjacency"
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [trill] Kathleen Moriarty's Discuss on draft-ietf-trill-transport-over-mpls-07: (with DISCUSS)

[Andrew G. Malis]

Kathleen,

I don’t want to speak for the authors. However, I did contribute to this
draft (although not this specific section). So that said, here’s my two
cents ….

I agree that first sentence could have been worded better, but the bottom
line is that depending on the model used, the security considerations for
RFC 7173, 4761, or 4762 applies, including the discussions in those RFCs on
issues such as isolation and end-to-end security. Those RFCs are referenced
in the security section. So the substance is already there, perhaps the
draft just needs better pointers to it.

Cheers,
Andy


On Wed, Mar 7, 2018 at 5:01 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-trill-transport-over-mpls-07: 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-transport-over-mpls/
>
>
>
> --
> DISCUSS:
> --
>
> I was very surprised to see the following in the security considerations
> section and would like to work with you on improvements.
>As an informational document specifying methods that use only
>existing standards and facilities, this document has no effect on
>security.
>
> Having watched many TRILL documents go by in the last 4 years, we didn't
> push
> too hard on security in some cases as a result of the restriction to a
> campus
> network.  This particular document extends into multi-tenancy where there
> are
> certainly security considerations introduced to be able to provide
> isolation
> properties.  MPLS offers no security and it is being used to join TRILL
> campuses as described int his draft.  This is done without any requirement
> of
> an overlay protocol to provide security - why is that the case?
> Minimally, the
> considerations need to be explained.  Ideally, a solution should be
> offered to
> protect tenants when TRILL campuses are joined.
>
>
>
>
> ___
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
>
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Kathleen Moriarty's Discuss on draft-ietf-trill-transport-over-mpls-07: (with DISCUSS)

[Kathleen Moriarty]

Kathleen Moriarty has entered the following ballot position for
draft-ietf-trill-transport-over-mpls-07: 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-transport-over-mpls/



--
DISCUSS:
--

I was very surprised to see the following in the security considerations
section and would like to work with you on improvements.
   As an informational document specifying methods that use only
   existing standards and facilities, this document has no effect on
   security.

Having watched many TRILL documents go by in the last 4 years, we didn't push
too hard on security in some cases as a result of the restriction to a campus
network.  This particular document extends into multi-tenancy where there are
certainly security considerations introduced to be able to provide isolation
properties.  MPLS offers no security and it is being used to join TRILL
campuses as described int his draft.  This is done without any requirement of
an overlay protocol to provide security - why is that the case?  Minimally, the
considerations need to be explained.  Ideally, a solution should be offered to
protect tenants when TRILL campuses are joined.




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

Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-directory-assisted-encap-10: (with DISCUSS)

[Alvaro Retana]

On March 7, 2018 at 4:48:35 PM, Donald Eastlake (d3e...@gmail.com) wrote:

Are these changes satisfactory?


Yes, these changes work for me.

Thanks!

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

Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-smart-endnodes-10: (with DISCUSS)

[Donald Eastlake]

Hi Alvaro,

On Mon, Mar 5, 2018 at 4:34 PM, Alvaro Retana  wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-smart-endnodes-10: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> This document feels tightly coupled with
> draft-ietf-trill-directory-assisted-encap, even though there are no
> cross-references.  If I understand the mechanisms correctly, a Smart Endnode
> (discussed in this draft) can then do directory assisted encapsulation
> (described in draft-ietf-trill-directory-assisted-encap).  In fact, the
> encapsulation/decapsulation seems to be the main motivation in defining a 
> Smart
> Endnode.

There are similarities, but I'm not sure I would say that
draft-ietf-trill-directory-assisted-encap and
draft-ietf-trill-smart-endnodes are "tightly coupled".

trill-directory-assisted-encap is the best you can do with no changes
to RBridges as specified in the TRILL Base Protocol [RFC6325]. Special
end stations can do the encapsulation but edge RBridges always do the
decapsuation.

trill-smart-endnodes requires additional mechanisms in the edge
RBridges to shake hands with the smart endnode, recognize when a
destination MAC is being handled by the smart endnode and just forward
it without decapslation, etc. As a result, this also support smart
endnodes that are fine grained label aware.

> I think then that this document also falls short in the exploration of
> potential issues, so I am also balloting DISCUSS.  The same cases that I
> pointed at for draft-ietf-trill-directory-assisted-encap [1] are applicable
> here -- with the added caveat that the Smart Endnode, in general, has other
> sources of information (learning, etc.), which means that there are 
> potentially
> more doors to close.

OK, similar security consideration text improvements can presumably be
made to this draft.

> The Multi-homing Scenario (Section 6) adds some complexity to the ability to
> check whether the Ingress RBridge is set correctly in the encapsulation.  It
> would be nice to explore this case a little further and highlight the issues 
> as
> the topologies get more complex.
>
> As I wrote in [1], I don't think that there are easy mitigations for these
> issues, but at least mentioning them so that operators are aware of the risk
> would be enough to clear this DISCUSS.  Given that the authors partially
> overlap, it may be a good idea to solve the issue in this document (which is
> the general case) and then just have the other one point this way.
>
> [1]
> https://mailarchive.ietf.org/arch/msg/trill/xZvEj_9FtSgHSp4DnKCVxr670gc/?qid=1e5a9496ac80237a3f7cc6aeea09d24d

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

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

[Donald Eastlake]

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 Gen-ART
> reviewer:
>
> All of section 4.3 is confusing as to what the length of the TLV really
is.
> Row 3 in the diagram says 2 bytes or 4 bytes, but the number of bits
called
> out
> in bullets 4 and 5 below it don't seem to add up to those things. Maybe it
> would
> be better to draw a diagram with F=0 and a separate diagram with F=1.
>
> Please make it clear both in the diagram and in the text what the expected
> lengths of the fields are -- I find it particularly confusing that the
> number
> of bits pictured doesn't align with 

Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-directory-assisted-encap-10: (with DISCUSS)

[Susan Hares]

Donald and Alvaro: 

Do we have an agreed upon text changes?   If so, can we send a proposed change 
to Alvaro for review prior to Thursday's meeting? 

Sue Hares

-Original Message-
From: Donald Eastlake [mailto:d3e...@gmail.com] 
Sent: Monday, March 5, 2018 3:27 PM
To: Alvaro Retana
Cc: The IESG; draft-ietf-trill-directory-assisted-en...@ietf.org; 
trill-cha...@ietf.org; Susan Hares; trill IETF mailing list
Subject: Re: Alvaro Retana's Discuss on 
draft-ietf-trill-directory-assisted-encap-10: (with DISCUSS)

Hi Alvaro,

On Mon, Mar 5, 2018 at 2:32 PM, Alvaro Retana  wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-trill-directory-assisted-encap-10: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> I have significant concerns about this document; as currently written, 
> I believe the technology is underspecified and can cause significant 
> damage to a DC network where it might be deployed.  I am then balloting a 
> DISCUSS.
>
> The document (including the security considerations) is written 
> assuming that the TRILL-ENs can be trusted (and are not compromised), 
> and that the directory information is accurate.  However, I believe 
> there are several cases that have been overlooked.
>
> (1) There aren't any basic safeguards specified to at least make sure 
> that a TRILL-EN is doing the right thing (or something sensible).  For 
> example, what if the Ingress RBridge Nickname field in the TRILL 
> header doesn't correspond to the first rBridge at the domain boundary?  
> Should that frame be accepted?

This concern doesn't seem very different from the general insecurity of Layer 2.

If a link has no TRILL router adjacencies, then I guess it it reasonable to 
check that the ingress nickname is that of the receiving RBridge but it gets 
harder if you have a mixed link with both end stations and TRILL routers 
(probably rare in deployments but, on the other hand, in TRILL a "link" can be 
a bridged LAN...).

> (2) rfc8171 talks about issues with incorrect directory mappings.  
> Consider the case where a TRILL-EN uses (on purpose!) an incorrect 
> mapping.  That "can result in data being delivered to the wrong end 
> stations, or set of end stations in the case of multi-destination packets, 
> violating security policy."
> [rfc8171]  How can this risk be mitigated?

I'm not sure how using "an incorrect mapping" is that different from just using 
whatever nicknames it feels like...

> I don't think that there are easy mitigations for these issues, but at 
> least mentioning them so that operators are aware of the risk would be 
> enough to clear this DISCUSS.

It is certainly reasonable to mention these. One possible mitigation is the use 
of end-to-end encryption.

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

Re: [trill] Alissa Cooper's Discuss on draft-ietf-trill-vendor-channel-00: (with DISCUSS and COMMENT)

[Donald Eastlake]

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 10:23 AM, Alissa Cooper  wrote:
>
> On Mar 6, 2018, at 11:11 PM, Donald Eastlake  wrote:
>
> Hi Alissa,
>
> On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper  wrote:
>
> Alissa Cooper has entered the following ballot position for
> draft-ietf-trill-vendor-channel-00: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> I'm having trouble understanding what function this specification serves
> given
> that the RBridge Channel Protocol registry has a range reserved already for
> private use and that the document doesn't specify any requirements around
> vendor-specific protocol semantics. So any implementation of this that needs
> to
> interoperate with another implementation will need to do so according to
> some
> specification generated by the vendor, and that specification can select a
> code
> point from the private use range. What does allocating a single code point
> for
> all such vendor-specific protocols achieve, aside from specifying a
> structured
> way of conveying the OUI/CID (which seems superfluous anyway for multiple
> implementations from a single vendor interoperating with each other)?
>
>
> What if two TRILL campuses using the same private code point for
> incompatible purposes are accidentally interconnected?
>
> What if someone wants to use TRILL switches from two different vendors
> each of which uses the same private code point for incompatible
> purposes? Say one vendor makes highly flexible/desirable edge TRILL
> switches while the other make particularly cost effective core TRILL
> switches or particularly nifty Level 1 / Level 2 border TRILL
> switches, or whatever.
>
> "private" code points seem pretty flakey compared with the more robust
> mechanism in this draft.
>
> Maybe this document should also depredate the use of private code points.
>
>
> Right, both of those examples make it sound like the purpose of having this
> document specify a code point is because the existing private use range is
> problematic. Your first example seems to directly contradict the guidance in
> RFC 7178 about the use of the private range, so if that is a real concern
> and it outweighs the utility of having the private range for private network
> use, then it seems like deprecation of the private range might make sense.
>
> The second example I see is the compelling use case for this. I will clear.
>
> Thanks,
> Alissa
>
>
> --
> COMMENT:
> --
>
> I agree with the Gen-ART reviewer that the text in the Acknowledgements
> section
> is not appropriate. See RFC 7322.
>
>
> OK.
>
> 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

Re: [trill] Kathleen Moriarty's No Objection on draft-ietf-trill-vendor-channel-00: (with COMMENT)

[Donald Eastlake]

Hi Kathleen,

On Wed, Mar 7, 2018 at 10:57 AM, Kathleen Moriarty
 wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-trill-vendor-channel-00: No Objection
>
> ...
>
> --
> COMMENT:
> --
>
> Could you please expand the text in the security considerations section as to
> why security properties (integrity, authentication, and encryption since they
> are not part of RBridge Channel messages except when explicitly added on in 
> the
> extension draft) were not built in?  I'm assuming it is the limited scope of
> use for the protocol.  I am glad that options exist to add it in, but wish the
> text were a bit more encouraging so that would actually happen.  Vendors need
> to be motivated to provide these options for customers who may want to use
> them, without that motivation, the features won't be provided.

OK.

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

[trill] Benjamin Kaduk's practice ballot (No Objection) on draft-ietf-trill-directory-assisted-encap-10 (with COMMENT)

[Benjamin Kaduk]

[incoming AD ramping up on document review; please treat as No
Objection with COMMENT]


RBridge is not defined in the document and it looks like only
"RBridge Channel" is marked as "well-known" in
https://www.rfc-editor.org/materials/abbrev.expansion.txt (but not
"RBridge" itself); perhaps I am misreading that page.


The qualitative differences in behavior between the cases where the
directory is known to (not) be complete seem worth mentioning in the
Introduction.  Maybe something like:

When the directory is known to be complete, additional efficiency
gains are possible: TRILL-ENs can drop packets for which there is no
valid destination, and RBridges that know that all attached end
nodes pre-encapsulate packets, unencapsulated packets can be dropped
as well.

or does that exclude the MAC address ingress filtering that the
RBridge can perform?


I would have benefitted from a legend for Figure 1.  At first I was
confused as to the difference between the 'T' nodes and the
vSwitches (and thus whether the vSwitches were outside the TRILL
Domain).


I'm not sure I understand the possible consequences of the TRILL-EN
spoofing the ingress nickname as that of the AF while still being
able to send it to/through any RBridge on its local link.  Is the
ingress nickname only used for return routing, in which case it
seems like the consequence is just that the AF just gets some extra
load, or are there other uses of it?  (This seems related to
Alvaro's DISCUSS.)


Section 5.1:

   For a large Data Center with hundreds of thousands of virtualized
   servers, setting the TRILL boundary at the servers' virtual switches
   will create a TRILL domain with hundreds of thousands of RBridge
   nodes, which has issues of TRILL Nickname exhaustion and challenges
   to IS-IS. On the other hand, setting the TRILL boundary at
   aggregation switches that have many virtualized servers attached can
   limit the number of RBridge nodes in a TRILL domain, but introduces
   the issue of very large MAC <-> Edge RBridge mapping tables to
   be maintained by RBridge edge nodes.

I could use a little more text on how the large MAC <-> Edge
RBridge mapping issue is avoided.


Security considerations:

OLD:
   The mechanism described in this document requires TRILL-ENs to be
   aware of the MAC address(es) of the TRILL edge RBridge(s) to which
   the TRILL-EN is attached and the egress RBridge nickname from which
   the destination of the packets is reachable. 

Do they need to know as a prerequisite, or do they learn this
information during the course of operation?  Maybe

NEW:
   The mechanism described in this document involve TRILL-ENs
   learning the MAC address(es) of the TRILL edge RBridge(s) to which
   the TRILL-EN is attached and the egress RBridge nickname from which
   the destination of the packets is reachable. 

Though it seems like this is just a subset of directory access,
which itself involves a lot of information about the TRILL topology.
Maybe it's better to phrase things in terms of that directory access
itself?

-Benjamin

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

[trill] Kathleen Moriarty's No Objection on draft-ietf-trill-vendor-channel-00: (with COMMENT)

[Kathleen Moriarty]

Kathleen Moriarty has entered the following ballot position for
draft-ietf-trill-vendor-channel-00: No Objection

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-vendor-channel/



--
COMMENT:
--

Could you please expand the text in the security considerations section as to
why security properties (integrity, authentication, and encryption since they
are not part of RBridge Channel messages except when explicitly added on in the
extension draft) were not built in?  I'm assuming it is the limited scope of
use for the protocol.  I am glad that options exist to add it in, but wish the
text were a bit more encouraging so that would actually happen.  Vendors need
to be motivated to provide these options for customers who may want to use
them, without that motivation, the features won't be provided.


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

Re: [trill] Alissa Cooper's Discuss on draft-ietf-trill-vendor-channel-00: (with DISCUSS and COMMENT)

[Alissa Cooper]

> On Mar 6, 2018, at 11:11 PM, Donald Eastlake  wrote:
> 
> Hi Alissa,
> 
> On Tue, Mar 6, 2018 at 3:28 PM, Alissa Cooper  > wrote:
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-trill-vendor-channel-00: Discuss
>> 
>> ...
>> 
>> --
>> DISCUSS:
>> --
>> 
>> I'm having trouble understanding what function this specification serves 
>> given
>> that the RBridge Channel Protocol registry has a range reserved already for
>> private use and that the document doesn't specify any requirements around
>> vendor-specific protocol semantics. So any implementation of this that needs 
>> to
>> interoperate with another implementation will need to do so according to some
>> specification generated by the vendor, and that specification can select a 
>> code
>> point from the private use range. What does allocating a single code point 
>> for
>> all such vendor-specific protocols achieve, aside from specifying a 
>> structured
>> way of conveying the OUI/CID (which seems superfluous anyway for multiple
>> implementations from a single vendor interoperating with each other)?
> 
> What if two TRILL campuses using the same private code point for
> incompatible purposes are accidentally interconnected?
> 
> What if someone wants to use TRILL switches from two different vendors
> each of which uses the same private code point for incompatible
> purposes? Say one vendor makes highly flexible/desirable edge TRILL
> switches while the other make particularly cost effective core TRILL
> switches or particularly nifty Level 1 / Level 2 border TRILL
> switches, or whatever.
> 
> "private" code points seem pretty flakey compared with the more robust
> mechanism in this draft.
> 
> Maybe this document should also depredate the use of private code points.

Right, both of those examples make it sound like the purpose of having this 
document specify a code point is because the existing private use range is 
problematic. Your first example seems to directly contradict the guidance in 
RFC 7178 about the use of the private range, so if that is a real concern and 
it outweighs the utility of having the private range for private network use, 
then it seems like deprecation of the private range might make sense.

The second example I see is the compelling use case for this. I will clear.

Thanks,
Alissa

> 
>> --
>> COMMENT:
>> --
>> 
>> I agree with the Gen-ART reviewer that the text in the Acknowledgements 
>> section
>> is not appropriate. See RFC 7322.
> 
> OK.
> 
> 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

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

[Alissa Cooper]

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.

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 Gen-ART
> reviewer:
> 
> All of section 4.3 is confusing as to what the length of the TLV really is.
> Row 3 in the diagram says 2 bytes or 4 bytes, but the number of bits called 
> out
> in bullets 4 and 5 below it don't seem to add up to those things. Maybe it 
> would
> be better to draw a diagram with F=0 and a separate diagram with F=1.
> 
> Please make it clear both in the diagram and in the text what the expected
> lengths of the fields are -- I find it particularly confusing that the number
> of bits pictured doesn't align with the number of bits specified in the text
> per field.
> 
> 
> --
> COMMENT:
> --
> 
> Please also look at the Gen-ART reviewer's other comments.
> 
> 
> 

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