Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10

Joe: 

I am confused as to your concerns.  I'll take this offline to see if I can get some clarity on the concerns.  Thank you for your continued comments on this document. 

Sue Hares 

-----Original Message-----
From: Joe Touch [mailto:touch@strayalpha.com] 
Sent: Friday, February 2, 2018 12:56 PM
To: Susan Hares
Cc: Magnus Westerlund; Donald Eastlake; tsv-art@ietf.org; trill IETF mailing list; draft-ietf-trill-over-ip.all@ietf.org; Alia Atlas
Subject: Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10

Hi Susan,

> On Feb 2, 2018, at 9:16 AM, Susan Hares <shares@ndzh.com> wrote:
> 
> Joe:
> 
> As WG chair, I need to manage the last of the WG calls for the TRILL.   We are closing the TRILL WG and pushing to handle all the drafts in an effective manner.  Therefore,  I am going to be more blunt that I normally am. 
> 
> Are you asking to utilize TLS/DTLS instead of IPSEC tunnel mode on a link?   

I’m indicating the doc fails to justify the required use of IP-level security for a transport encapsulation solution. 

> Are you suggesting to run a routing protocol should intermix with data forwarding without security? 

No. 

> If you are asking a draft to be rewritten at this point to explain these issues, I would like some substantiating background or theory from the routing side to indicate why you feel TLS/DTLS is better than an IPSEC tunnel or that a routing protocol should not be protected within a secure tunnel against data traffic.  The directions you are asking to document has not be successful in routing IGPs or path vector protocols.

Trill goes inside TCP or UDP in this doc. For that part of the path anything that protects that payload is sufficient. If the payload needs to be protected elsewhere ie before or after this transit then that is a separate issue. 

> 
> If you are suggesting a tutorial is added to a protocol document, provide operational reasons why this should be contained within a TRILL protocol specification.   If you feel that these reasons for these choices should be document in an independent draft, then you are welcome to suggest this to Alia Atlas.  I'm sure that Donald Eastlake will consider an independent draft explain reasons if Alia Atlas thinks it is useful. 

None of this is relevant to my comment. 

> I will hold the WG LC for trill-over-ip until Monday morning at noon ET (9am PT) while you start a focused discussion on this topic.  By Monday at noon ET, this discuss needs to come to a conclusion.   
> 
> Sue Hares 
> Trill co-chair
> 
> -----Original Message-----
> From: trill [mailto:trill-bounces@ietf.org] On Behalf Of Joe Touch
> Sent: Friday, February 2, 2018 10:34 AM
> To: Magnus Westerlund
> Cc: Donald Eastlake; tsv-art@ietf.org; trill IETF mailing list; draft-ietf-trill-over-ip.all@ietf.org
> Subject: Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10
> 
> Hi, all,
> 
> This doc is very confusing.
> 
> Its title and discussion throughout indicates “TRILL over IP”, including figs in Sec 4, but the only actual encapsulations described are TRILL over UDP and TRILL over TCP.
> 
> IMO, this needs a very deep scrub to resolve. It would help to understand that the root issue is that the encapsulation headers are *all* those added to the TRILL packet trying to transit the IP network; there’s no “inserting” of encapsulation between IP and TRILL.
> 
> That includes:
> 
> - explaining why you require IPsec tunnel mode, when the encapsulations presented would be completely secure using TLS/DLS or any variant of IPsec on the encapsulated traffic
> 
> - explaining the relation between TRILL MTU discovery and the MTU of the transport level, and how these interact (or could interfere) with each other
> 
> - why are not other more obvious encapsulations being considered, notably any TCP/UDP encapsulation that already supports Ethernet, including GRE (which might then allow this doc to be condensed to instructions for configuration, rather than trying to specify a new encapsulation system)
> 
> Joe
> 
> 
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill
> 