Re: [netconf] Securing UDP-notif messages with DTLS

[Pierre Francois <[e-mail]>]

Benoit,

It works for me.

Pierre.

Le mar. 3 août 2021 à 14:45, Benoit Claise <[e-mail]> a
écrit :

> Hi,
>
> This discussion reminds me of IPFIX discussions :-)
> Considering that the industry/operators will implement what they need (not
> more), or request what they need from router vendors, regardless of the
> RFCs say, let's go with the path of least resistance regarding publication.
> I would say: merge the two drafts.
>
> Regards, Benoit
>
> On 8/2/2021 9:22 PM, Pierre Francois wrote:
>
> Juergen,
>
> Thanks for your input.
>
> IESG composition won't change much to the story on this aspect, I think.
>
> Alright, I'll discuss with all the authors involved and get back to the
> list. I guess no one in the wg will object to a merge if we decide to go
> this way.
>
> Cheers,
>
> /pfr
>
>
>
>
>
>
> Le lun. 2 août 2021 à 19:33, Jürgen Schönwälder <
> [e-mail]> a écrit :
>
>> In the past, there were people on the IESG that would tell you that "a
>> controlled environment" is in most cases a myth. (There is something
>> to this argument once you think about how messed up the world appears
>> to be these days.)
>>
>> There certainly is a point that compliant implementations must support
>> a secure transport so that people deploying the technology have the
>> choice to use it. If an operator then decides to not use the secure
>> transport, so be it, that is then the operator's free choice (and
>> responsibility). But not being able make this choice, because a secure
>> transport is not universally implemented, is an obstacle to avoid.
>>
>> And yes, this is all about what needs to be implemented to be
>> compliant. The IESG has little influence on what people use, but it
>> can influence that people have a choice by requiring the
>> implementation of a secure transport by compliant implementations.
>>
>> /js
>>
>> PS: Of course, I am talking from past experience, and the details of
>>     the story lines usually change with the IESG composition.
>>
>> On Mon, Aug 02, 2021 at 07:14:35PM +0200, Pierre Francois wrote:
>> > Hello everyone,
>> >
>> > I'm fine with merging the two drafts. What I wish is that the existing
>> > implementations that do not mandate dtls activation remain legit wrt the
>> > resulting RFC.
>> > We're aiming at lightweight transport in controlled environments here.
>> >
>> > Cheers,
>> > Pierre.
>> >
>> > Le lun. 2 août 2021 à 18:26, Kent Watsen <[e-mail]> a écrit :
>> >
>> > >
>> > > Mahesh and I were wondering about this.  When Pierre mentioned the
>> DTLS
>> > > work, we were “surprised” in that we too assumed the “udp” draft had
>> the
>> > > security bits.
>> > >
>> > > It is true that the IESG is all but mandating security for a for years
>> > > now.  IIRC, Syslog over UDP is obsolete due to being unsecured.
>> > >
>> > > K.
>> > >
>> > > On Aug 2, 2021, at 11:53 AM, Zmail <[e-mail]>
>> wrote:
>> > >
>> > > Noted, I’ll discuss this with Unyte team.
>> > >
>> > > Alex
>> > >
>> > > On 2 Aug 2021, at 11:40, Jürgen Schönwälder <
>> > > [e-mail]> wrote:
>> > >
>> > > Since I doubt that a protocol not providing security will receive
>> > > IESG approval, I suggest that this work is getting integrated into
>> > > draft-ietf-netconf-udp-notif-03.txt.
>> > >
>> > > I have not read the content but the I-D seems fairly small so
>> > > integration into the WG document should be fairly trivial. Given past
>> > > experience, it might be that the DTLS/UDP transport will become the
>> > > mandatory to implement transport.
>> > >
>> > > /js
>> > >
>> > > On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote:
>> > >
>> > > Hello to everyone,
>> > >
>> > > We would like to present a new draft we didn’t have time to show on
>> the
>> > > last IETF meeting.
>> > >
>> > > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/
>> <
>> > > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/>
>> > >
>> > > This draft defines a mechanism to secure UDP-notif protocol messages
>> using
>> > > DTLS 1.3.
>> > > It defines the different layers involved, the DTLS session lifecycle
>> and
>> > > the mandatory cipher suites to use. It also explicits that no
>> extensions of
>> > > DTLS are needed and that IP fragmentation should be avoided.
>> > > We would like to have some feedback for this draft.
>> > >
>> > > We will present the draft to the WG on the next IETF meeting.
>> > >
>> > > Looking forward to hearing from you,
>> > >
>> > > Alex Huang Feng
>> > >
>> > >
>> > > _______________________________________________
>> > > netconf mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/netconf
>> > >
>> > >
>> > >
>> > > --
>> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> > > Fax:   [phone]         <https://www.jacobs-university.de/>
>> > >
>> > >
>> > > _______________________________________________
>> > > netconf mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/netconf
>> > >
>> > > _______________________________________________
>> > > netconf mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/netconf
>> > >
>>
>> > _______________________________________________
>> > netconf mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]         <https://www.jacobs-university.de/>
>>
>
> _______________________________________________
> netconf mailing [e-mail]://www.ietf.org/mailman/listinfo/netconf
>
>
>