Subject: Re: registering tunnel types

From: tom petch <[email-masked]>
Date: Fri, 2 Nov 2018 16:26:15 +0000

---- Original Message -----
From: "Joel Jaeggli" <[email-masked]>
To: "tom petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Alexandre
Petrescu" <[email-masked]>
Sent: Tuesday, October 30, 2018 8:23 PM

> On Oct 30, 2018, at 05:07, tom petch <[email-masked]> wrote:
>>
>
> Alex
>
> I agree, at least in part; tunnels and interfaces are different
animals
> and it is unfortunate that they were conflated in SMI.
>
> I was surprised that NETMOD had not produced a YANG module for tunnels
> but it seems that there has been no need for the past decade.  That
> said, I think that it is a good idea to have one.  Whether or not it
> should mirror the Tunnel MIB I find more debatable.

It’s not entirely obvious to me that netted / netconfig would be where
the tunnel models were produced.

They tend if fact to be produced by the tunnel protocol maintainers e.g.
l3sm/l2sm/ccamp and so on. The management tools for a product tend to be
developed itself in my experience.

<tp>

Joel

My concern is that something that cuts across a number of IETF WG should
get adequate review.  The YANG interface module was much discussed in
the netmod WG, with an existing MIB as guidance, before becoming an RFC.

The proposed YANG tunnel module, which borrows the concepts of the
interface module, that additions should be made by the Tunnel MIB
Designated Expert to a registry and then propagated to the Tunnel MIB
and the Tunnel YANG module, has not been discussed in any WG.  The
proposal, as I mentioned before, has been added to the I-D after IETF
Last Call has been completed so appears to me to be the work of one
individual, without any review; the I-D lists seven editors, six of whom
appear to be absent.  TheWG mailing list seems devoid of any discussion.

I believe that the IETF succeeds because of peer review, and I struggle
to see that here.

Tom Petch

> My own homework came across other IP in IP varieties which do not
> appear.
>
> Tom Petch
>
>
>>
>> Alex
>>
>>>
>>> If you need a new value or if you have a question about a given
> interface tunnel type, please follow the guidelines in the url cited
> above. All this is out of the scope of draft-ietf-softwire-yang.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : ipv6 [mailto:[email-masked]] De la part de Alexandre
> Petrescu
>>>> Envoyé : jeudi 25 octobre 2018 09:54
>>>> À : [email-masked]
>>>> Objet : Re: registering tunnel types
>>>>
>>>> Are:
>>>> -IPv6 in UDPv4 and
>>>> -IPv6 in IPv6 as used by openvpn;
>>>>
>>>> covered by the list below?
>>>>
>>>> These are a few tunnelling mechanisms I use routinely.
>>>>
>>>> Existing identity 6tofour should be deprecated, if that means 6to4,
>>>> which is deprecated.
>>>>
>>>> Existing identity iphttps has a version number for IP?
>>>>
>>>> Alex
>>>>
>>>> Le 24/10/2018 à 17:57, tom petch a écrit :
>>>>> draft-ietf-softwire-yang
>>>>> completed IETF Last Call two weeks ago and, since then, has
> acquired a
>>>>> YANG module that defines tunnel types, as listed below.  It is
> intended
>>>>> to be a IANA-maintained module and so changes to the list of
> tunnels
>>>>> will not require a reissue of the softwires RFC-to-be.  At the
> same
>>>>> time, getting it right first time never did any harm so if anyone
> can
>>>>> think of any missing, or can think of other places where there
> might be
>>>>> other tunnels lurking, now would be a good time to mention it.
>>>>>
>>>>> It is based on RFC4087 Tunnel MIB (which created an SMI Textual
>>>>> Convention that went up to Teredo) so tunnels from that vintage
> are
>>>>> likely well catered for.  softwires is not where I would have
> first
>>>>> looked for tunnel types, but it has a certain logic to it.
>>>>>
>>>>>       identity  other
>>>>>
>>>>>       identity direct
>>>>>
>>>>>       identity gre
>>>>>
>>>>>       identity minimal
>>>>>
>>>>>       identity l2tp
>>>>>
>>>>>       identity pptp
>>>>>
>>>>>       identity l2f
>>>>>
>>>>>       identity udp
>>>>>
>>>>>       identity atmp
>>>>>
>>>>>       identity msdp
>>>>>
>>>>>       identity sixtofour
>>>>>
>>>>>       identity sixoverfour
>>>>>
>>>>>       identity isatap
>>>>>
>>>>>       identity teredo
>>>>>
>>>>>       identity iphttps
>>>>>
>>>>>       identity softwiremesh
>>>>>
>>>>>       identity dslite
>>>>>
>>>>>       identity  aplusp
>>>>>
>>>>> Tom Petch
>>>>>
>>
>>>> -------------------------------------------------------------------
-
>>>>> IETF IPv6 working group mailing list
>>>>> [email-masked]
>>>>> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
>>
>>>> -------------------------------------------------------------------
-
>>>>>
>>>>
>>
>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [email-masked]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>
>>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked] <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
<https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Nov 2018 10:24:59 +0100

Le 25/10/2018 à 15:43, Michael Richardson a écrit :
> Alexandre Petrescu <[email-masked]> wrote:
>      > Are:
>      > -IPv6 in UDPv4 and
> Since there is a layer of proprietary encryption in openvpn, the answer is
> no.

This deserves consideration, because I am using it.

What is that layer of proprietary encryption in openvpn and how can I 
replace it?

Is it some proprietary (not publicly nor freely available specs) 
encryption algorithm?

Alex

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Nov 2018 07:53:51 -0500

Alexandre Petrescu <[email-masked]> wrote:
    >> Since there is a layer of proprietary encryption in openvpn, the
    >> answer is no.

    > What is that layer of proprietary encryption in openvpn and how can I

Your only real choice is that can stop using openvpn.
It's a proprietary vertical, and it does not contain end-user replaceable
pieces.

    > Is it some proprietary (not publicly nor freely available specs)

OpenVPN uses a variety of standard cipher algorithms (3DES, AES-CBC, probably
AES-AEAD modes too), but the way in which it uses it proprietary.

It does not use RFC4303 constructs on the wire in particular.
Finally, a publically available specification (even in the form of open
source code), does not make the mechanism standard.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Nov 2018 14:24:26 +0100

> Your only real choice is that can stop using openvpn.

And use what instead? (SoftEther?)

> It does not use RFC4303 constructs on the wire in particular.

It uses at least TLS, which does have an RFC number.

OpenVPN payloads seem recognized by open Wireshark dissectors.

OpenVPN port numbers seem understood and acted upon by firewalls.

> source code), does not make the mechanism standard.

Do you mean that because we dont have an OpenVPN RFC it makes it risky?

(just like we dont have a Skype RFC makes it so)

Alex