Re: [trill] RtgDir review: draft-ietf-trill-directory-assisted-encap-02

[Donald Eastlake]

Hi Ben,

Thanks for your review. It appears that is was not responded to in a
timely fashion. Apologies on behalf of the authors.

(Your review was of the -02 version. The current version is -05.)

On Sun, Apr 24, 2016 at 4:28 AM, Ben Niven-Jenkins
 wrote:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review. The purpose of the review is to provide assistance to the
> Routing ADs. For more information about the Routing Directorate,
> please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing
> ADs, it would be helpful if you could consider them along with any
> other IETF Last Call comments that you receive, and strive to
> resolve them through discussion or by updating the draft.
>
>
> Document: draft-ietf-trill-directory-assisted-encap-02.txt
> Reviewer: Ben Niven-Jenkins
> Review Date: 21 April 2016
> Intended Status: Proposed Standard
>
> Summary:
> I have significant concerns about this document and recommend that
> the Routing ADs discuss these issues further with the authors.

Hopefully the changes made between the version -02 you reviewed and
the current -05 have made some improvements and, based on your
comments and WG LC comments, further improvements can be made.

> Comments:
> Overall this is not the easiest document to read although some of
> that might be due to my lack of background in TRILL and its
> terminology.
>
> Major Issues:
>
> 1) The document has an Intended Status of Proposed Standard, however
> it does not contain any RFC2119 keywords and does not seem to make
> any normative statements about required behaviour which I would have
> expected in a Proposed Standard.

Well, in version -05 there is at least one keyword instance.
Furthermore, I don't know that such keywords need to always be used
when an implementation requirement level is being specified. That
said, we could see if additional RFC 2119 keywords are warranted.

> 2) Section 4: If I understand correctly the TRILL-EN spoofs the
> Ingress RBridge edge node's nickname in the source address field of
> the TRILL header. Is this likely to introduce problems? E.g. if
> RBridges will accept & forward frames that have their own source
> address in, does it perpetuate routing loops or present security
> considerations that the document should discuss?

TRILL goes to great lengths to avoid loops and has a hop count in the
TRILL header so that, should there be a transient loop, a TRILL packet
in that loop (i.e., an encapsulated frame) will be discarded. In the
potentially more dangerous case of multi-destination packets, as
compared with known unicast, where copies could multiply due to forks
in the distribution tree, a Reverse Path Forwarding Check is used to
discard packets that appear to be on the wrong link or when there is
disagreement about the distribution tree.

Security Considerations should probably say more on this.

> Section 8 on Security Considerations also looks very light on
> text. If you are allowing TRILL-ENs to spoof RBridge source
> addresses (which I think you are, see comment above) I think you
> should have a discussion about that somewhere in the document.

I agree that some further discussion is needed in the Security
Considerations section.

> Minor Issues:
>
> 1) Section 3. I am not sure what Figure 2 is trying to convey and it
> is not referred to by the main text. Is it required?

Figure 2 is intended to show the header of a pre-encapsulated frame
going from a TRILL-EN to an edge TRILL switch. If it is retained in
the draft, there should be clarifying text that references it.

> 2) Section 3 says:
>
>Editor's note: [Directory] has defined Push and Pull methods for edge
>RBridges to get directory mapping information. The Pull Model is
>relative simple for TRILL-EN to implement (see Section 9). Pushing
>Directory information requires some reliable flooding mechanism, like
>the one used by IS-IS, between the edge RBridge and the TRILL
>encapsulating node.
>
> which gives me the impression the authors prefer pull and discourage
> push as it would require something extra like IS-IS.

That note no longer exists in the draft. Also the "[Directory]" draft
referred to has been issued as RFC 8171 and the draft should be
updated to reflect that.

> However, Section 4 says
>
>The TRILL-EN learns this nickname by listening
>to the TRILL IS-IS Hellos from the Ingress RBridge.
>
> which makes me think if the TRILL-EN is running IS-IS for hellos, is
> pushing the directory such an obstacle?

That text refers to snooping on IS-IS messages, not running IS-IS.

There are problems with using IS-IS, designed for communication
between routers (Intermediate Systems) and the end station
implementing pre-encapsulation as described 

Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Eric,

I realize that most of the delay has been on the TRILL WG end but I hope
you don't mind if I ping you again on looking at the -09 revision of this
draft...

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

On Mon, Oct 9, 2017 at 7:05 PM, Donald Eastlake  wrote:

> Hi Eric,
>
> A -09 version of draft-ietf-trill-arp-optimization has been posted. Could
> you look at it to see if it resolves your comments?
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
> On Mon, Oct 2, 2017 at 2:12 PM, Eric Rescorla  wrote:
>
>>
>>
>> On Mon, Oct 2, 2017 at 4:54 PM, Donald Eastlake  wrote:
>>
>>> Hi Eric,
>>>
>>> My apologies for the delay in response. (For part of the time I was on
>>> a cruise...)
>>>
>>> It looks like we are in agreement on most items.
>>>
>>> See below.
>>>
>>> On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla  wrote:
>>> >
>>> >
>>> > On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake 
>>> wrote:
>>> >>
>>> >> Hi Eric,
>>> >>
>>> >> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla  wrote:
>>> >> > Eric Rescorla has entered the following ballot position for
>>> >> > draft-ietf-trill-arp-optimization-08: Discuss
>>> >> >
>>> >> > 
>>> --
>>> >> > DISCUSS:
>>> >> > 
>>> --
>>> >>
>>> >> As a general comment, the Security Consideration section could use
>>> >> clarification and some expansion.
>>> >>
>>> >> Although one can imagine various mixed modes, to the first
>>> approximation
>>> >> there are two ways of doing the optimization of various
>>> multi-destination
>>> >> messages discussed in this document:
>>> >>
>>> >> + Using data plane learning by observing ARP/ND and similar messages
>>> (in
>>> >> addition to the learning of MAC addresses from the data plane which is
>>> >> enabled by default in TRILL). As described in this document, such
>>> data plane
>>> >> learning by TRILL switches can be used to sometimes optimize
>>> >> ARP/ND/RARP/unknown-destination messages. But the result isn't
>>> particularly
>>> >> more or less secure than it is when this data plane learning is done
>>> by end
>>> >> stations rather than by TRILL switches (or bridges or other kinds of
>>> >> switches) in the middle doing some optimization of the relevant
>>> >> multi-destination messages. Interface address information learned
>>> through
>>> >> data plane learning by edge TRILL switches can also be propagated via
>>> the
>>> >> control plane but this is not significantly different from
>>> propagating that
>>> >> information via the multi-destination messages that are being
>>> optimized to
>>> >> unicast or optimized away.
>>> >> + Using a complete, trusted directory as might be based on an
>>> orchestration
>>> >> system in a data center. Since the messages between TRILL switches
>>> doing
>>> >> ARP/ND/RARP/unknown-destination optimization can be secured and the
>>> TRILL
>>> >> switches can be configured to ignore data plane learning, this
>>> enables TRILL
>>> >> switches to provide answers that are "correct" in that they
>>> correspond to
>>> >> the data in this complete, trusted directory. However, there can
>>> still be
>>> >> various forged messages/addresses on a local link between end
>>> station(s) and
>>> >> edge TRILL switches. Such a local link can, with TRILL, be a bridged
>>> LAN, so
>>> >> such forgeries emitted by an end station may be seen by other end
>>> stations
>>> >> and cause incorrect learning from the data plane.
>>> >>
>>> >> The existing Security Considerations section is a bit sketchy and
>>> >> concentrates more on the data plane case, as that is the one with the
>>> >> greatest security challenges.
>>> >
>>> > Yes, this seems like a reasonable assessment. Alia, does someone have
>>> the
>>> > action item to make it less sketchy?
>>>
>>> We are working on a draft revision to reflect the above thinking to a
>>> greater extent and decrease sketchiness.
>>>
>>> >> > It's not clear to me how the security properties of this mechanism
>>> >> > compare to existing TRILL. The text says:
>>> >> >
>>> >> >Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages
>>> can be
>>> >> >easily forged. Therefore the learning of MAC/IP addresses by
>>> RBridges
>>> >> >from ARP/ND should not be considered as reliable. See Section
>>> 4.1 for
>>> >> >SEND Considerations.
>>> >> >
>>> >> > "not considered as reliable" seems suboptimal. You need to cover how
>>> >> > this mechanism compares to the non-use of this mechanism.
>>> >>
>>> >> As above, the optimization mechanisms do not make any significant
>>>