Subject: Re: [mpls] AD review of draft-ietf-mpls-tp-ethernet-addressing

From: Stewart Bryant <[email-masked]>
Date: Fri, 01 Feb 2013 15:35:50 +0000

On 11/01/2013 22:29, Adrian Farrel wrote:
> Hi,
>
> I have conducted my usual AD review of your document as part of the
> publication request processing. The aim of my review is to catch any
> issues that might show up in IETF last call, directorate reviews, or
> IESG evaluation. The intent is to resolve the issues by text changes
> or through email discussion to smooth the passage of the document
> through the later stages of the process.
>
> I have reviewed this document jointly with draft-ietf-mpls-gach-adv
> and since the author team is the same for the two documents, I
> recommend that you process the comments for the two documents at the
> same time.
>
> As usual, all my comments are open for disagreement and discussion. I
> think that you will probably want to produce a revision of this
> document to address my comments, so I have put it into "Revised I-D
> Needed" state in the data tracker.
>
> Thanks for the work,
> Adrian
>
> ===
>
> The abbreviations GAL and OAM are not used in the document and can be
> removed from Section 1.1.
Done
> ---
>
> Am I missing something? Why do you only support 48-bit MAC addresses?
We have added text specifying the use of EUI-64 and noting that
the mapping is defined by the IEEE (and good luck understanding
the IEEE formal and tutorial text).

> ---
>
> I am *really* surprised that this document does not mention LLDP. In
> [I-D.ietf-mpls-gach-adv] you state...
>
>     Where
>     it is anticipated that the sole purpose of the GAP will be to provide
>     Ethernet MAC address learning, the use of LLDP SHOULD be considered.
>
> So this document needs to say the same thing (all over and in 18pt red
> bold). Furthermore, it needs to define what "HOULD" means in this
> context.
We have added text on this.

>
> ---
>
> In Section 4...
>
> Could you please identify (with TBD1 - to be assigned by IANA) the
> application ID of the new "Ethernet Interface Parameters" application.
We put this in the IANA section.
>
> Could you please state: "The format of the TLVs is as defined in
> [I-D.ietf-mpls-gach-adv].
Done
>
> Could you please include the type values for the two TLVs you are
> defining (so that people don't have to look ahead to the IANA section).
Done
>
> Since the two TLVs you are defining have predictable lengths, it would
> be nice if you included the specific length values to be used.
Done
> ---
>
> I think section 4 is missing something. It is clear from
> [I-D.ietf-mpls-gach-adv] that at least one TLV must be present in the
> Ethernet Interface Parameters" ADB element. Is there a requirement that
> the Source MAC Address TLV is always present? What are the rules for
> multiple occurrences of either of the TLVs you have defined?
>           

We say

Where MAC address learning occurs by some other means, this TLV group 
MAY be used to advertise only the MTU. If multiple adverisements are 
made for the the same parameter, use of these advertisments is undefined.
>          
> ---
>
> Somewhere, probably Section 4, should leverage the stated intention in
> [ID.ietf-mpls-gach-adv] by stating that the values received in the new
> ADB element SHOULD (or probably MUST) be made accessible for inspection
> by network operators, and where local configuration is updated by the
> received information, it MUST be clear why the configured value has
> been changed. Furthermore, you probably need to discuss whether
> information learned in this way is allowed to be persistent across
> node or interface discontinuities. (The last point suggests to me that
> you might want to include a brief section on handling changes in
> adjacent MAC addresses - a point that you have given as a motivation
> for the work.)
We have added a new section

Manageability Considerations

The values sent and received by this protocol MUST be made accessible 
for inspection by network operators, and where local configuration is 
updated by the received information, it MUST be clear why the configured 
value has been changed. The advertised information SHOULD be persistent 
across restarts. Received advertisements MUST be discarded across 
restarts. If the received values change, the new values MUST be used and 
the change made visible to network operators.

> ---
>
> In my comments on [I-D.ietf-mpls-gach-adv] I ask about the consequences
> of message loss. This issue seems to apply to this document so,
> depending on how you handle the issue in [I-D.ietf-mpls-gach-adv] you
> may need to add something to this document.
Added

In the event of the persistent loss of the GAP messages, the receiving 
node MUST assume that it is now connected to a node that does not 
support these advertisements and must behave as configured for this 
eventuality.

>
> ---
>
> Section 5 should reference [I-D.ietf-mpls-gach-adv] for the security
> properties of the GAP. It should probably note that an effective
> attack is modifying the Source MAC Address value, while modifying the
> MTU value may also have significant consequences. Furthermore, it may
> be the case that visibility into the contents of either of the TLVs
> could provide information that is useful for an attacker.

An attacker could disrupt communications by modifying the Source MAC 
Address or the MTU values, however this is mitigated by the use of 
cryptographic authetication as described in <xref
target="I-D.ietf-mpls-gach-adv">
which also describes other considerations applicable to the GAP 
protocol. Visibility into the contents of either of the TLVs could 
provide information that is useful for an attacker. This is best 
addressed by physical security of the links.
> ---
>
> In section 6.1, please include an IANA action to update the reference
> for the MAC address to point to the RFC number assigned to this
> document on publication.
Done, although they usually catch this.
> ---
>
> In section 6.2, could you please replace 0x0001 with TBD1.
Done
>
> ---
>
> Trivial point, but there are precisely three authors, all marked as
> editors. You could safely dispense with the "editor" designation (on
> the front page and in the Authors' Addresses section).
>
> .
>
Done

New version to be uploaded shortly

Stewart & Dan