[trill] I-D Action: draft-ietf-trill-over-ip-16.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transparent Interconnection of Lots of Links 
WG of the IETF.

Title   : TRILL (Transparent Interconnection of Lots of Links) 
Over IP Transport
Authors : Margaret Cullen
  Donald Eastlake
  Mingui Zhang
  Dacheng Zhang
Filename: draft-ietf-trill-over-ip-16.txt
Pages   : 51
Date: 2018-03-18

Abstract:
   The TRILL (Transparent Interconnection of Lots of Links) protocol
   supports both point-to-point and multi-access links and is designed
   so that a variety of link protocols can be used between TRILL switch
   ports. This document specifies transmission of encapsulated TRILL
   data and TRILL IS-IS over IP (v4 or v6) transport. so as to use an IP
   network as a TRILL link in a unified TRILL campus. This document
   updates RFC 7177 and updates RFC 7178.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-trill-over-ip-16
https://datatracker.ietf.org/doc/html/draft-ietf-trill-over-ip-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-over-ip-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[trill] Protocol Action: 'TRILL Multilevel Using Unique Nicknames' to Proposed Standard (draft-ietf-trill-multilevel-unique-nickname-07.txt)

[The IESG]

The IESG has approved the following document:
- 'TRILL Multilevel Using Unique Nicknames'
  (draft-ietf-trill-multilevel-unique-nickname-07.txt) as Proposed Standard

This document is the product of the Transparent Interconnection of Lots of
Links Working Group.

The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-multilevel-unique-nickname/





Technical Summary

   TRILL routing can be extended to support multiple levels by building
   on the multilevel feature of IS-IS routing. Depending on how
   nicknames are managed, there are two primary alternatives to realize
   TRILL multilevel: the unique nickname approach and the aggregated
   nickname approach as discussed in [MultiL]. This document specifies a
   unique nickname approach. This approach gives unique nicknames to all
   TRILL switches across the multilevel TRILL campus.

Working Group Summary

Consensus strong on this methodology. 

A word on TRILL WG: 
TRILL working worked on the multi-level, multiple topology work 
item together over the last 3+ years.  The WG operates with 
high discussion level at IETFs for these new features, and 
individuals working hard on drafts between time. 
During the last 12 months, early drafts in the 
multi-level,  multiple topology (E.g. RFC8243) 
have been approved. 

Document Quality

Huawei and IPInfusion have TRILL implementations, 
Scaling work was engaged in to aid long-term growth. 
No implementations of this draft have been done. 

On responses about known IPR by authors, Honjun Zhai did reply
on Feb 9 and Donald forwarded Dongxin Liu's email reply to the
trill mailing list on Feb 20.

Personnel

Document Shepherd: Susan Hares
AD: Alia Atlas 

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

[trill] Protocol Action: 'TRILL (TRansparent Interconnection of Lots of Links): Address Flush Message' to Proposed Standard (draft-ietf-trill-address-flush-06.txt)

[The IESG]

The IESG has approved the following document:
- 'TRILL (TRansparent Interconnection of Lots of Links): Address Flush
   Message'
  (draft-ietf-trill-address-flush-06.txt) as Proposed Standard

This document is the product of the Transparent Interconnection of Lots of
Links Working Group.

The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/





Technical Summary

The TRILL (TRansparent Interconnection of Lots of Links) protocol,
   by default, learns end station addresses from observing the data
   plane.  In particular, it learns local MAC addresses and edge
   switch port of attachment from the receipt of local data frames and
   learns remote MAC addresses and edge switch of attachment from the
   decapsulation of remotely sourced TRILL Data packets.

   This document specifies a message by which a TRILL switch can
   explicitly request other TRILL switches to flush certain MAC
   reachability learned through the decapsulation of TRILL Data
   packets.  This is a supplement to the TRILL automatic address
   forgetting and can assist in achieving more rapid convergence in
   case of topology or configuration change.

Working Group Summary

No.  This draft is part of a package of directory/ARP services
for TRILL.  Flushing unused MAC learned MAC addresses is key to
keeping the bridge-router function scalable. A late IPR disclosure
required a second WG Last Call but caused no concern or contention.

Document Quality

   Huawei has implemented a subset of this protocol.

Personnel

  Document Shepherd: Susan Hares  
  Responsible AD: Alia Atlas 

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

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

[Alvaro Retana]

Thanks Donald!

On March 15, 2018 at 1:25:07 AM, Donald Eastlake (d3e...@gmail.com) wrote:

A -07 version of draft-ietf-trill-multilevel-unique-nickname has been
posted with the intent of resolving your comment as per my response
below.
___
trill mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] Eric Rescorla's No Objection on draft-ietf-trill-over-ip-15: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-trill-over-ip-15: 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-over-ip/



--
COMMENT:
--

Based on my conversation with DEE, I understand that the HMAC is always
computed over a value which is disjoint with the HKDF-Label. This is not really
cryptographically ideal -- as I stated in my review, you should be HKDFing two
keys off the same key -- but it does imply that the trivial attack doesn't
work, so I'm removing my DISCUSS. As we discussed, please add some explanation
of why this is a non-issue to the document.


___
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)

[Kathleen Moriarty]

Hi Donald,

Thanks for your response, inline.

On Wed, Mar 14, 2018 at 4:52 PM, Donald Eastlake  wrote:
> Hi Kathleen,
>
> On Wed, Mar 14, 2018 at 2:28 PM, Kathleen Moriarty
>  wrote:
>> Hi Donald,
>>
>> Thanks for the proposed text.  Please see inline.
>>
>> On Mon, Mar 12, 2018 at 10:01 PM, Donald Eastlake 
>> wrote:
>>> Hi Kathleen,
>>>
>>> Would the following replacement Security Considerations section for
>>> draft-ietf-trill-transport-over-mpls be adequate?
>>>
>>>
>>>This document specifies methods using existing standards and
>>>facilities in ways that do not create new security problems.
>>>
>>>For general VPLS security considerations, including discussion of
>>>isolating customers from each other, see [RFC4761] and [RFC4762].
>>>
>>>For transport of TRILL by Pseudowires security consideration, see
>>>[RFC7173]. In particular, since pseudowires are support by MPLS or IP
>>>which are in turn supported by a link layer, that document recommends
>>>using IP security or the lower link layer security.
>>>
>>>For added security against the compromise of data end-to-end
>>>encryption and authentication should be considered; that is,
>>>encryption and authentication from source end station to destination
>>>end station.
>>
>> Would this be accomplished through IPsec?
>
> For end-to-end security, it could be. Or DTLS. Whatever is convenient for
> the information you want to protect. Since end stations are connected to
> edge TRILL switches via Ethernet, if you wanted to protect all of the data
> between two end stations, you could use IEEE Std 802.1AE. Do you want a list
> added?

Yes, I think that would be helpful.  Thank you.
>
>> If encryption and authentication are not employed, what are the risks
>> to tenant isolation since this draft joins TRILL campuses?
>
> I wouldn't say that the draft "joins TRILL campuses". If a TRILL campus is
> actually structured so that the connectivity being provided is connecting
> two islands, then you could say it is making those TRILL switches parts of
> the same campus. The term "campus" in TRILL is not intended to have any
> geographic (or academic) implication but rather, to be for TRILL switches
> the same as the term "bridged LAN" is for IEEE 802.1 bridges.
>
> Whenever a link extends outside local physical control, there is increased
> risk. Assuming a link between two TRILL switch ports in a TRILL campus is
> Ethernet, it could be anything from a little copper on a backplane inside a
> cabinet to Ethernet connectivity purchased from a carrier and extending
> hundreds of miles.
>
> If you are talking about the risk of a TRILL campus merging with a malicious
> TRILL switch, that can be avoided by IS-IS PDU authentication. Until
> adjacency is establish (RFC 7177), which requires successful exchange of
> IS-IS Hellos PDUs, no data will flow.
>
>> I think
>> there should be text that explains this risk in addition to the text
>> already proposed.
>
> How about adding text like the following:
>
>
> Transmission outside the customer environment through the provider
> environment, as described in this document, increases risk of compromise or
> injection of false data through failure of tenant isolation or by the
> provider. In the VPLS model (Section 3), the use of link encryption and
> authentication between the CEs of a tenant that is being connected through
> provider facilities should be a good defense. In the VPTS model (Section 4),
> it is assumed that the CEs will peer with virtual TRILL switches of the
> provider network and thus link security between TRILL switch ports is
> inadequate as it will terminate at the edge PE. Thus, end station to end
> station encryption and authentication is more appropriate for the VPTS
> model.


That's helpful, thanks for the proposed text.

Best regards,
Kathleen

>
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e...@gmail.com
>
>> Thanks,
>> Kathleen
>>
>>>
>>>For general TRILL security considerations, see [RFC6325].
>>>
>>>
>>> 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 5:35 PM, Andrew G. Malis 
>>> wrote:

 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

Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-over-ip-15: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Sun, Mar 18, 2018 at 12:21 PM, Donald Eastlake  wrote:

> Hi Eric,
>
> On Sun, Mar 18, 2018 at 4:56 AM, Eric Rescorla  wrote:
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-trill-over-ip-15: Discuss
> >
> > ...
> >
> > --
> > DISCUSS:
> > --
> >
> > Hopefully this is easy to resolve. In the best case, you will be
> > able to demonstrate that this is not a problem in practice and
> > document that. If not, the actual fix is straightforward, though
> > incompatible.
> >
> > S 7.1.1.
> > I am concerned about the use of the IS-IS key in this way. First, on
> > general principles, you should not use a single key both as input to a
> > KDF and directly as a working key. Specifically, however, RFC 5310
> > defines the use of HMAC authentication with IS-IS-key as the HMAC
> > key, and HKDF-Expand is really just SHA-256. Thus, if an attacker
> > was able to observe (or cause to be created) an IS-IS packet that
> > happened to have the same contents as the HKDF Info value you
> > provide would then know the IKE PSK.
> >
> > The correct practice here is to separately expand both the IS-IS
> > key *and* the IKE PSK from the same original value. If you cannot
> > do that, you should at least generate an Info value which is
> > guaranteed to not be the input to any RFC 5310 MAC.
>
> The source may not be easily accessible.
>
> The first byte of the data to which the RFC 5310 MAC is applied is always
> 0x83, the Interdomain Routeing Discriminator. The first byte of the data
> below is 0x54 ('T') so they cannot be the same.
>
>  HKDF-Expand-SHA256 ( IS-IS-key,
>  "TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-Port )
>
>
> Could also add some text such as "Note that the value to which the HKDF
> function is applied starts with 0x54 ('T') while the data to which RFC 5310
> authentication is applied (an IS-IS PDU) starts with 0x83, the Interdomain
> Routeing Discriminator, thus, although they are both SHA256 based, they are
> never applied to the same value."
>

OK. This is not cryptographically ideal (you really should be deriving two
separate keys from HKDF) but given this I am not aware of any weakness. We
could presumably consult with someone like Karthik Bhargavan or Hugo
Krawczyk, but I imagine you'd just get "we don't know of any problems", but
it's not great, which is more or less my position.

Based on this, I will withdraw my DISCUSS and assume that Alia can shepherd
these changes.


>When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that
> >incorporates the IS-IS shared key in order to bind the TRILL data
> >session to the IS-IS session.  The pre-shared key that will be used
> >
> > The technique you provide does not guarantee a binding between the
> > sessions. It merely ensures (modulo the caveat above) that both sides
> > know the IS-IS Key. It's easy to see this by noting that you could
> > move IS-IS traffic from one IPsec association to another. If you
> > actually want to bind these sessions, you must do something different.
>
> I think the idea was just that, in conjunction with the text later in this
> section, the IPsec key wouldn't be used for longer than the IS-IS key.
>
> How about just deleting the words "in order to bind the TRILL data session
> to the IS-IS session."?
>

That seems fine to me.


>
> > --
> > COMMENT:
> > --
> >
> > I see that native encapsulation is incompatible with NATs (S 8).
> > That's probably worth stating upfront to minimize confusion.
> >
> > S 5.4.2.
> >
> >   f. No middleboxes are allowed in the TRILL over IP transport link
> >  because middlebox support is beyond the scope of this document.
> >
> > How would you know if no middleboxes were in the link?
>
> Well, if they map IP addresses, the "neighbor" values inside the Hellos
> will not get mapped, will not match, and thus you will be unable to
> establish adjacency and nothing will flow over the link except Hellos (no
> data, LSPs, etc.). You need an application specific gateway for TRILL to
> operate through a NAT. On the other hand, a sufficiently benign middlebox
> (if there are such things) which, for example, only had a black list of
> some IP protocols / ports / addresses, that had no effect on the TRILL data
> or control traffic would be pretty invisible and TRILL should work fine
> through it.
>
> How about the following replacement text:
>
> f. This document assumes there are no middleboxes in the path and thus
> does not cover restrictions on such middleboxes. Middlebox support is
> beyond the scope of this document.
>
>
SGTM.


> S 5.5.
> > Can you use VXLAN with IPsec?
>
> "VXLAN" is really Ethernet over VXLAN 

Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-over-ip-15: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Eric,

On Sun, Mar 18, 2018 at 4:56 AM, Eric Rescorla  wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-trill-over-ip-15: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> Hopefully this is easy to resolve. In the best case, you will be
> able to demonstrate that this is not a problem in practice and
> document that. If not, the actual fix is straightforward, though
> incompatible.
>
> S 7.1.1.
> I am concerned about the use of the IS-IS key in this way. First, on
> general principles, you should not use a single key both as input to a
> KDF and directly as a working key. Specifically, however, RFC 5310
> defines the use of HMAC authentication with IS-IS-key as the HMAC
> key, and HKDF-Expand is really just SHA-256. Thus, if an attacker
> was able to observe (or cause to be created) an IS-IS packet that
> happened to have the same contents as the HKDF Info value you
> provide would then know the IKE PSK.
>
> The correct practice here is to separately expand both the IS-IS
> key *and* the IKE PSK from the same original value. If you cannot
> do that, you should at least generate an Info value which is
> guaranteed to not be the input to any RFC 5310 MAC.

The source may not be easily accessible.

The first byte of the data to which the RFC 5310 MAC is applied is always
0x83, the Interdomain Routeing Discriminator. The first byte of the data
below is 0x54 ('T') so they cannot be the same.

 HKDF-Expand-SHA256 ( IS-IS-key,
 "TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-Port )


Could also add some text such as "Note that the value to which the HKDF
function is applied starts with 0x54 ('T') while the data to which RFC 5310
authentication is applied (an IS-IS PDU) starts with 0x83, the Interdomain
Routeing Discriminator, thus, although they are both SHA256 based, they are
never applied to the same value."

>When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that
>incorporates the IS-IS shared key in order to bind the TRILL data
>session to the IS-IS session.  The pre-shared key that will be used
>
> The technique you provide does not guarantee a binding between the
> sessions. It merely ensures (modulo the caveat above) that both sides
> know the IS-IS Key. It's easy to see this by noting that you could
> move IS-IS traffic from one IPsec association to another. If you
> actually want to bind these sessions, you must do something different.

I think the idea was just that, in conjunction with the text later in this
section, the IPsec key wouldn't be used for longer than the IS-IS key.

How about just deleting the words "in order to bind the TRILL data session
to the IS-IS session."?

> --
> COMMENT:
> --
>
> I see that native encapsulation is incompatible with NATs (S 8).
> That's probably worth stating upfront to minimize confusion.
>
> S 5.4.2.
>
>   f. No middleboxes are allowed in the TRILL over IP transport link
>  because middlebox support is beyond the scope of this document.
>
> How would you know if no middleboxes were in the link?

Well, if they map IP addresses, the "neighbor" values inside the Hellos
will not get mapped, will not match, and thus you will be unable to
establish adjacency and nothing will flow over the link except Hellos (no
data, LSPs, etc.). You need an application specific gateway for TRILL to
operate through a NAT. On the other hand, a sufficiently benign middlebox
(if there are such things) which, for example, only had a black list of
some IP protocols / ports / addresses, that had no effect on the TRILL data
or control traffic would be pretty invisible and TRILL should work fine
through it.

How about the following replacement text:

f. This document assumes there are no middleboxes in the path and thus does
not cover restrictions on such middleboxes. Middlebox support is beyond the
scope of this document.


> S 5.5.
> Can you use VXLAN with IPsec?

"VXLAN" is really Ethernet over VXLAN over UDP. I don't see a problem with
doing Ethernet over VXLAN over UDP over IPsec.

> S 5.6.
> What security mechanism do you expect to use for TCP? IPsec again?

Yes.

>the timing and implementation details may be such that P! and P2 each
>
> Nit: P1, right?

Yes, sorry about that pesky shift key...

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-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] Alvaro Retana's No Objection on draft-ietf-trill-address-flush-05: (with COMMENT)

[Donald Eastlake]

Version -06 posted as requested.

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

On Sun, Mar 18, 2018 at 7:16 AM, Alia Atlas  wrote:

> Donald,
>
> Could you please submit this ?
>
> Thanks,
> Alia
>
> On Wed, Mar 14, 2018 at 8:32 PM, Donald Eastlake  wrote:
>
>> Hi Alvaro,
>>
>> Attached is a candidate -06 version of draft-ietf-trill-address-flush
>> (my internal version 39) intended to resolve your comments. Also
>> attached is a diff against the currently posted -05. Can you take a
>> looks and see if your comments are satisfied?
>>
>> Thanks,
>> Donald
>> ===
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>> 
>>  d3e...@gmail.com
>>
>>
>> On Thu, Feb 8, 2018 at 11:39 AM, Donald Eastlake 
>> wrote:
>> > Hi Alvaro,
>> >
>> > On Wed, Feb 7, 2018 at 12:28 PM, Alvaro Retana 
>> wrote:
>> >> Alvaro Retana has entered the following ballot position for
>> >> draft-ietf-trill-address-flush-05: No Objection
>> >>
>> >> ...
>> >>
>> >> --
>> >> COMMENT:
>> >> --
>> >>
>> >> I have some non-blocking comments/questions:
>> >>
>> >> (1) Why are the 2 VLAN Block encodings needed?  More important, when
>> should
>> >> each be used?  Section 2.2 says that "All RBridges implementing the
>> Address
>> >> Flush RBridge Channel message MUST implement types 1 and 2, the VLAN
>> types...",
>> >> but I didn't see anything about the VLAN Block Only Case (2.1).  I'm
>> wondering
>> >> if there will be cases where the support won't match and the message
>> will then
>> >> be ineffective.
>> >
>> > I suppose some wording could be added but the idea is that the VLAN
>> > Block Only Case is part of the basic message and always has to be
>> > implemented, as opposed to the extensible list of TLV types. The
>> > message is structured so that you can't use both the VLAN Block Only
>> > Case and the extensible TLV structure to specify VLANs at the same
>> > time. The VLAN Block Only Case is expected to be common and
>> > corresponds more closely to deployed code.
>> >
>> >> (2) In the 2.2.* sections, the description of some of the TLVs says
>> (when the
>> >> Length is incorrect) that "...the Address Flush message MUST be
>> discarded if
>> >> the receiving RBridge implements Type x".  What if that type is not
>> supported
>> >> -- I would assume you still want to discard?  BTW, the Type 5
>> description
>> >> doesn't qualify dropping based on the type support.
>> >
>> > If the Type is not implemented, then how would you know that the
>> > length is not valid? How would you currently code a length validity
>> > check for types to be specified in the future as part of the
>> > extensibility of the message? But, since there is a length field, you
>> > can always skip over a TLV you don't understand. The qualification
>> > based on type support should be there for Type 5 also. (Of course, in
>> > the real world, I think inconsistent Address Flush message type
>> > support in a TRILL campus will be very rare.)
>> >
>> >> (2a) Other descriptions (type 1,2,6) just talk about ignoring (not
>> discarding).
>> >>  Is there an intended difference in the behavior?
>> >
>> > There is no intended difference between "ignoring" and "discarding" an
>> > Address Flush message. (Types 1, 2, and 6 are the mandatory to support
>> > types so there is no conditional on support.)
>> >
>> >> (3) Section 2 says that "Address Flush protocol messages are usually
>> sent as
>> >> multi-destination packets...Such messages SHOULD be sent at priority
>> 6".  It is
>> >> not clear to me whether unicast packets (mentioned later) should also
>> have the
>> >> same priority.
>> >
>> > Yes, probably throwing in "including unicast Address Flush messages"
>> > would clarify.
>> >
>> > Thanks,
>> > Donald
>> > ===
>> >  Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-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 mailing list
trill@ietf.org
https://www.ietf.org/mailman/listinfo/trill

[trill] I-D Action: draft-ietf-trill-address-flush-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transparent Interconnection of Lots of Links 
WG of the IETF.

Title   : TRILL (TRansparent Interconnection of Lots of Links): 
Address Flush Message
Authors : Weiguo Hao
  Donald E. Eastlake
  Yizhou Li
  Mohammed Umair
Filename: draft-ietf-trill-address-flush-06.txt
Pages   : 22
Date: 2018-03-18

Abstract:
   The TRILL (TRansparent Interconnection of Lots of Links) protocol, by
   default, learns end station addresses from observing the data plane.
   In particular, it learns local MAC addresses and edge switch port of
   attachment from the receipt of local data frames and learns remote
   MAC addresses and edge switch of attachment from the decapsulation of
   remotely sourced TRILL Data packets.

   This document specifies a message by which a TRILL switch can
   explicitly request other TRILL switches to flush certain MAC
   reachability learned through the decapsulation of TRILL Data packets.
   This is a supplement to the TRILL automatic address forgetting and
   can assist in achieving more rapid convergence in case of topology or
   configuration change.





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trill-address-flush/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-trill-address-flush-06
https://datatracker.ietf.org/doc/html/draft-ietf-trill-address-flush-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-address-flush-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

[trill] Eric Rescorla's Discuss on draft-ietf-trill-over-ip-15: (with DISCUSS and COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-trill-over-ip-15: 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-over-ip/



--
DISCUSS:
--

Hopefully this is easy to resolve. In the best case, you will be
able to demonstrate that this is not a problem in practice and
document that. If not, the actual fix is straightforward, though
incompatible.

S 7.1.1.
I am concerned about the use of the IS-IS key in this way. First, on
general principles, you should not use a single key both as input to a
KDF and directly as a working key. Specifically, however, RFC 5310
defines the use of HMAC authentication with IS-IS-key as the HMAC
key, and HKDF-Expand is really just SHA-256. Thus, if an attacker
was able to observe (or cause to be created) an IS-IS packet that
happened to have the same contents as the HKDF Info value you
provide would then know the IKE PSK.

The correct practice here is to separately expand both the IS-IS
key *and* the IKE PSK from the same original value. If you cannot
do that, you should at least generate an Info value which is
guaranteed to not be the input to any RFC 5310 MAC.

   When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that
   incorporates the IS-IS shared key in order to bind the TRILL data
   session to the IS-IS session.  The pre-shared key that will be used

The technique you provide does not guarantee a binding between the
sessions. It merely ensures (modulo the caveat above) that both sides
know the IS-IS Key. It's easy to see this by noting that you could
move IS-IS traffic from one IPsec association to another. If you
actually want to bind these sessions, you must do something different.


--
COMMENT:
--

I see that native encapsulation is incompatible with NATs (S 8).
That's probably worth stating upfront to minimize confusion.

S 5.4.2.

  f. No middleboxes are allowed in the TRILL over IP transport link
 because middlebox support is beyond the scope of this document.

How would you know if no middleboxes were in the link?

S 5.5.
Can you use VXLAN with IPsec?

S 5.6.
What security mechanism do you expect to use for TCP? IPsec again?

   the timing and implementation details may be such that P! and P2 each

Nit: P1, right?


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