Internet Engineering Task Force 104, 26 Mar 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF104-ANIMA-20190326-1350

Description

ANIMA meeting session at IETF104
2019/03/26 1350

https://datatracker.ietf.org/meeting/104/proceedings/

A

Knowlton so because I think we're.

B

Missing their house.

A

B

This this was basically this like that I, so.

A

C

Is also saying out.

A

So I, for example, wouldn't ask for adoption in France that I've done, because you know this is awful. Overloaded I mean.

D

We can remove that, but you need to say this right.

E

I will tend to say.

E

What's your time, oh, if you won okay, hello well, anyway,.

F

That's a gender wait: where is they.

E

F

Time, five, thirty or fifty actually it's time to start.

E

G

F

Okay, we're helping you know in this ridiculous name which speeds a room into two and has a very big crime. What attention.

H

Attention what butter? Okay,.

F

Thanks this is the animal working group if you're having in the wrong room. You still have time to get out to this most video crisis, meeting room, who ever say he has two separate rooms with very big chrome inside anyway. Here we are now we have two hours.

F

Yeah, let's, let's use their not world, everybody should already say that so many times the Renwick and the meeting before so, everybody should read lot carefully and operators who was I'm not going to read that through here.

A

F

So as no no, we would like to mention to everyone the ministries of the official working place, so people should have say on I discussing paternity organs they between those meetings, so the face-to-face meeting areas only you know, discuss those questions, rest in the minister and make more people aware iam and try to serve down the conclusions and more information could be found in the list at the webpage. This is the meeting agenda. For today we have the poof and they're. Just the working group document update.

F

We actually have three working good document updating today, but I actually moved two of them into the rescue sub session. So there's just one adjoining the country plan for 10 minutes, then that's a potential new charter and scrumpy.

F

We push sake minutes. There hope that's not enough soon, as the information distribution in Ottoman Canada working its individual draft, that wastes things that's actually in the scope for the current charters and also for the proposed new charter. So it's you know a little bit priority.

F

Next is the meeting agenda for the sub setting of risky. We have seven drafts there of him. Currently working group draft, obviously what we would like to is to have the priority for the working group document. They can tell as long as they want and also we would like to work the working group to get. You know more review on this document and the try to you know finish that as soon as we could then- and we have one sanera and requirements for layer.

F

Two autonomic control plans are individual draft because we are in the process of the Charter so with giving little time for the individual drafts for this meeting. But if we successfully get our Richard her done before the next meeting, we could have more time for a new draft new individual draft and it's possible. We have two sessions for next mission and he shows for the agenda, but in the bash.

H

So we had our ad tell us that closer that one of the issues that have been brought forward to him was the view. Wanna maybe talk to it yourself. Yes, yes,.

I

So, first thing not issues just to give the context. Over the last year, I have had approached by four people, saying that both co-chairs of anime have the same affiliation and, while I don't necessarily see this as a problem, and this is not something unique. We had such cases and actually have such cases too.

I

What I would like to do is to ask the working group whether they see this as something troubling and if, yes, what should be done by that I'm simply relaying the feedback from the community that they notice this, and they ask such a question so just to be very clear. This is not an escalation from ad saying that something is not right. This is providing the feedback from the community that I got. So if you could discuss that and I think the the whole working group could discuss. That would be good.

I

If you have something to stay, for example, right now come to the mic, call it open mic very briefly and and state your opinion.

J

Hi Elliot, responding to higness his point. I did notice that the both chairs have the same affiliation. I have not noticed that this has been a problem hmm and I would raise the issue if I thought it was a problem and at the moment I don't see it and until I do see it. For me, it's not a problem.

C

No in Somalia I also noticed changing affiliation, but it was more than a year ago, something like this, but I've not seen any issue so far in how to work a new child I've been managing the group or the documents so far. For me, it's not an issue.

I

Anyone else has anything to say: oh right, so can we do like this and that let's, let's keep this window C open for a week, was all two weeks after after the meeting and if you have anything send out to the mailing list, but the message that I'm getting that this is not a problem for the working group at this time. I think that will be just silent closed and that's it not a working.

H

I

H

By the way, I think we also skipped about the always nasty piece of the notes, taker right, so I think we already.

F

H

F

F

A

F

Okay, this gives you the very brief summary of what we had the working group. We had two are say already published last year in May, and we actually should have more because we have three documents already passed: the iesg process, one actually in two years ago, and actually two in 2017 and wine in master. The one bore the reference model they already but rocked by miss rife. So whenever the actually the ASAP gets through, we will have those full artists together.

F

So that's actually giving York- and you know most headache- focus now yeah, it's the ASAP, so we would its submit to ASC for publication early last year, but still now always the ist. We have three discuss and given the most latest information I got from others. We should be able to do that in while to Mars alrighty.

I

So this is what I was going to ask. Of course, both the responsible ad and one of the ideas holding the discuss will change this week. So I think it's it's already too late to try to do anything here. But basically, what is your plan of addressing that? The responsibility is still the question moving historically, that has been on the terrorist side. Maybe it will happen. We had a brief discussion with Eric.

I

Maybe that document will come to me, which will be probably more logical but I think that doesn't change the discuss hold a problem as one of a security ad is changing.

H

Right so from from the understanding having talked to other folks, Eric is leaving, and so I can I can show the changes done to resolve the discuss and that there was done against the review from Eric and from Benjamin and so I would. Our expectation was that hopefully, Benjamin would take care of reviewing both of these feedbacks because they were also. You know. A lot of the discuss were overlapping, the third one from Alicia, actually and Jen art I think was already resolved. Last time, I just didn't try to ping Alicia to say clear.

H

The discuss, because I first wanted to work on the big chunk. Where was a security one so and and if, if basically Benjamin is to overload it I mean he does a lot of things then willing to find another reviewer, so otherwise I think he could maybe take care of also Eric's.

H

Because he's he's kind of you know he spent a really large and good amount of time in reviewing that stuff. Also I.

I

Think right, so, if you're asking me right now, I don't have what to answer I'm, just saying from CMO from administrative position: what's the situation of that, but if you say that the discussion of the Benjamin is ongoing, I think that is fine, yeah, so I think.

H

Benjamin said that, obviously after ITF he can come back, okay and and review the the nineteen and I think at that point in time we can check if we need to get somebody else involved or if you can take care of Eric's feedback as well. Thank you, I mean and I'm, not just saying it from the perspective of I think he would be the best person of already having delved into the matter and having all the discusses. If there is some you know, iesg process that says somebody else needs to do it then no.

I

Simply discuss needs to be cleared by the ad arising in the discuss once lady changes, it's the new idea, which inherits that well in head of the whole document and he has to go through. Naturally, he probably doesn't understand the whole context and other things that that will just delay things.

I

Again and well, you had a previous slide on the actual brewski, so I've been looking into the comments which are coming in as a resolution, mostly for the IOT, Directorate and I believe that that addresses most of the concerns and in a current state of waiting for idea, ad write-up I would say that, once you feel that you're happy with those commands as the changes which we went into the document are substantial, we'll need to do an ITF last call for that document. Once again, and once that is done, it will progress.

F

A

A

Go ahead, take the advantage information versus was the ACP I uploaded. It huh didn't take crazy.

A

Where is the ACP slides I? Don't.

C

Know you have loaded them.

H

Waiting for data tracker waiting I should have that snatch earlier yeah.

F

Oh, you can use your net there.

E

Yeah yeah yeah thanks.

A

That works so full screen again: okay,.

D

You can do it.

A

B

Cruel perfectly.

H

Okay, so this is the update of the ACP traffic, so we had 18 primarily doing the review of jernard and Alicia and a few other outstanding feedback comments and ITF 103. So this time the version 19 was published before ITF 104 doing the feedback for the very extensive iesg security review from erequest collar and benjamin kellogg.

H

We think that that version addresses all the outstanding iesg review comments and they don't introduce any functional changes to the ACP, but they're really just a lot of you know answering two questions: explanations and refining off the mandatory IP ii DTLS profile. So the details of you know what you need to do in IPSec and DTLS to ensure interoperability so right, so many textual engineering improvements.

H

So the first interesting architectural aspect that people couldn't understand without me, adding more text was that you know the support for constraint devices opportunistic in this document. This text is in there, so we do include DTLS as an alternative, secure channel protocol to IPSec, primarily for the perspective of explaining the ACP architecture and the negotiation and the ability to support different protocols.

H

But that is not complete support for constraint devices out of which one class would be characterized by only supporting you know any product called other than TCP right, so device that hey TCP, for whatever reason too much scope space history. So we still have dependencies against TCP. Some of the components, for example, est for certificate renewal, which we mend a to be supported, would have to be defined over UDP or coop. Likewise, the grasp in the ACP we're also doing across TCP right now.

H

So we think this would be better work for a follow-up document to really then focus on the constraint devices completely. So.

H

Yeah there were so these are just a bunch of detailed, so one of one of the important part was how ACP can also help secure bootstrap. That was I, think not well written. So you know the security aspect that the ACP brings to bootstrap was primarily also meant to existing non brewski. Boot strap because brewski itself is secure, but the hop-by-hop encryption also hides the communication patterns. Like you know the addresses of the communicating entities, so that's another level of security that end-to-end encryption, even insecure, bootstrap cannot provide by itself.

H

Then we have the section for which kind of you know was very confusing with the musts and should it had in there and in 103 I had a special form of underscore must underscore should to highlight that this is actually a stub that was done to emphasize the requirements that the working group came up against an ACP in the beginning when we started the animal working group, but we weren't allowed to have from the Charter separate requirements documents because everybody was afraid we would kind of waste too much time on requirements document.

H

So this, basically the requirements are actually lower specified in that section. Then, for example, what the ACP ultimately does right so basically says you should really have encryption and ultimately the ACPs we do. It now says you must have encryption and that basically was confusing, so hopefully now we'll get to the end of having as much explanation and correct formalism in there. So these are not. Capital must anymore, because this is just informative going into the document.

H

Likewise, explanation for the RFC 80 to 20, to field and- and that was pretty much- we choose that encoding- also because we're a little bit of rate of raising requirements against low-end devices to support additional asn.1 decoding of previously undefined asn.1 fields. So that was one of the reason why we chose this. You know textual encoding into an RFC eighty, eight twenty two field, so security review, obviously so got a lot of good feedback to help revisit the text to be more specific about the ACP domain membership check.

H

So one of the things is that obviously we want to do certificate path, validation, which means you can have a master CA sub C. A assigning CA so can have chain of CAS. That will be checked, then also the problem that, because this is bringing up connectivity, you know first by itself you may not be able to have you know, certificate, revocation list or an OCSP server connectivity initially.

H

So that was where details added how to deal with that which basically means yet well, if you don't have the information, you first built the connectivity, but if you actually figure out later that the only connection you have to the internet or to the rest of the ACP is through a device that you learn, you know has a remote certificate. Well, then goodbye your network connectivity through the ACP rather be secure than have connectivity.

H

In that case ya, then, basically, brewski is mentioned a lot of places now, as kind of really the preferred example on how to do the secure bootstrap and obviously a and I devices must have brewski. But if you just want to implement a CP with any other form of bootstrap, that's fine as well, but yeah. The reviewers were mentioning that all the brewski details are fairly dense and you must read brewski.

H

So that's what the text now says if you're interested in using a CP with brewski read the following section: otherwise skip it and please I'm going quickly through this, so please raise your hand or make yourself you know known. If you don't understand anything, one understand anything better. Alright, so then also the trust, points and trust anchors, so I was trying to summarize, you know, I think, hopefully a good one-page explanation of what they mean.

H

What the terminology is, because there were two or three points that I had to add in response to the feedback and I. Think that you know anybody who was not a security ad might even be more overwhelmed by the security aspects that the ACP introduces. So this is hopefully one good additional page of explanations. Yeah make sake. So we only mentioned this as and as an example. So there is nothing about Mexico in the document at all.

H

That was clarified, then the whole way on how to nodes discover each other and assign the roles of Ellis and pop. In the setup of the secure channel, that was also just dense text, and now there is a one page, long step by step diagram with each individual message being explained and related to each other. Why?

H

Okay, you do this message because you had the following message in the prior step, so that was also asked for so now the you know the real functional refinements and if there is still anything you know missing of all these hundreds of parameters in IPSec I very much welcome anybody who knows that formalisms better to suggest additional text, but what it now says is ESP with aes-256 GCM, as used in RFC 4106 I was asking around a little bit and it seems that this gal, our counter mode, is well enough, supported in the hardware that we would like to support with IPSec and in many cases might even have a higher performance and work better than the prior modes.

H

Key establishment must support EC DHE with P 256. Don't even ask me anymore: I, don't remember anymore. What this means. I was looking through that all that IPSec stuff finding reference and hope. That's the right text.

H

Dtls actually was easier because Eric had appointed me last year to RFC 7525, which is a very good description of recommended DTLS profile, and the only change we really did was to say that we don't really care about supporting interoperability with DTLS 1:1, so raise the bar to say, must use DTLS, 1 or 2 or later.

H

Right and then also the other texts about you know there is no mandatory to implement secure channel protocol. It really only depends on what type of role you have in the network, so we're specifying the general purpose. You know one particular class of a CP router general purpose. Router must do IPSec, but if you say you know I'm just an IOT, a CP router, then you might only implement DT or less, and it's not a problem, because there is.

H

This is not about end-to-end connectivity where everybody needs to have a common MTI, but this is just hop by hop so across your backbone, you're just running, for example, a CP with IPSec. Then you have a gateway note that does IPSec empty TLS and then in your iot edge you're only using DTLS. So hopefully this is now sufficiently well explained that nobody stumbles across this anymore umm right. So a couple of I think yeah, the acp registrar's text I think we're already running short on time, so yeah.

H

So the ripple text that Pascal and I put together. You know on second reading. The introduction section was very technical, so after you've gone to a ripple university, you would understand it so I try to rewrite it that it basically is more logical and explanatory for people to whom ripple is new, which I think was the case for the security reviewers.

H

Then, of course, also edit, the you know, precise sentence about the benefit over the IGP, which effectively is there a lot fewer routes, especially when you get to the edge of the network right and of course, yes, we don't use ripple security as it specified, because we instead have the ACP secure channels underneath it ICPs TP interactions, benefits right, so.

H

It's yes self-healing! So yes, so this was basically specifically adding to the benefits section effect that we're actually raising the bar on maintaining actual. You know, authentication of the secure channels, because they're long lived- and you know they may be as long lived as that you know they may be. The trade of the other site may be revoked or expired in the meantime, and at that point in time you know the requirements against the ACP in the normative section already said, you must revisit that and hear down the connection.

H

If that happens, so then operations right, we're saying what ACP could be used for and then basically I got the please add the twenty RFC's for all these normative documents for all these protocols. Okay, that was fun um then, basically the whole. What configuration does the ACP need, because it does seem to you know, have a lot of configurable aspects in it and basically I wrote a you know in this 10.4, which is operational in, which is information which is not specification, part really trying to highlight the fact you know only know.

H

Acp configuration is good acp configuration, so everything that this configuration is the exception, and basically those are the things that we haven't figured out so far how to make magically auto configuring right.

H

So that's, basically the bootstrap config, which, with brewski, can be very simple: the CA certificate, server, est servers, ACP connect to connect non ACP notes and then, if you're in a brownfield environment, while you need some magic command, which already has good documentation to enable the ACP or to build ACP tunnels right so I mean these are really from our perspective, exceptions- and you know, with you know, with pre standard implementation. We've built networks where you know there was very, very simple security considerations.

H

Of course, um there was also in the details in terms of they were claiming that there is no configuration needed for the ACP, which is also one of the reasons why I detailed all these kind of exception cases up front in the prior section, and we reverted the initial paragraph to highlight that. Obviously you know you have this bootstrap, however, it you do it, but once you have been any ACP domain certificate and you don't need this stuff well, you know it is fully self operating.

H

Then, of course also the highlight the ACP registrar's are really critical infrastructure and they need to be hard and similarly to how you need to harden a certificate authority right. So if you attack the sea ace, you can take over the network right, so the the registrar's or the CAS you can take over the network right and then you know, I was trying to detail that peer-to-peer security model that we have peer-to-peer because really with the domain certificates, you can just connect.

H

You know, however many or few ACP nodes with each other without dependency on any. You know not back-end or other stuff, so you can use that in ad hoc networks. However, you like it, that's why we chose the peer to peer group security and then also discuss that the certificate can be reused in higher levels for end-to-end security, but in those uses you very often would rather like to have you know more role. Differentiation, not every node, should have the same authorization in other nodes and that already exists in Section a 10 5.

H

So there is just a pointer from the security section to that one yeah and the expiry during channel lifetimes. We already had that so I in a consideration, so this whole why we chose the name. Served on xxx was strange, so hopefully that's better explained. Now, then that was basically the discussion in the security review. How about compromised, ACP nodes and well Appendix? A means this is all kind of the.

H

You know, text on the fringes anyhow, but after reviewing what the problem really is and we've seen that in the practical deployments, as well as the compromised ACP nodes right, the the main issues credential leakage right so, for example, passwords for administrator access getting to somebody else, and the ACP already has some good amount of protection against the operator doing something bad, because even such an attacker will have a very hard time shouldn't be able at all to bring down the ACP.

H

So, even if the attacker is trying to take over your node well, if you don't have too many, you know, CL is for the ACP and the ACP is continuously running. He can't even connect you from the network and other parts like yeah.

H

You shouldn't have you know local CLI to establish operator credentials anyhow, so it was kind of my perspective on what really, from my experience, the most important step you can take in implementations to create devices where the impact of compromised notes are minimized or the chance to even have notes compromised is minimized so yeah. That was it so, hopefully a lot of useful explanatory text, edit.

K

H

K

You said: there's issues dealing with as URL and OCSP servers not being reachable, but you control the other end of this communication right. You could mandate OCC OCSP stapling and be done with it. That's true, but if that note is.

H

Attacked and compromised, it may not do this anymore, but.

K

I mean not do it if you don't get a staple, you say: yeah I'm, not gonna, talk to you. If the staple is bad. I'm not gonna, talk to you right, but.

H

But I think one of the points is also that, as I said later in the slide deck that we want to support the case where you don't have your knock back-end with all these big servers running right.

H

So if you, if you basically just connect three or four ACP nodes together right at that point in time, you know none of them may have OCSP or a crl. Well,.

K

H

K

Certificates like and and they have connectivity to the OCSP server I can vouch for that certificate. No I'm saying they're a complete Island where they can't act. Anything else so.

H

You don't know what time.

K

It is either because you don't want to be ready, no.

H

No I mean if I look at typical deployments that we had like, let's say, a a site in an enterprise that is losing its internet link and all the big servers are basically behind that internet link right. You still have locally in the site the ACP running right.

K

But this is this: only an issue when you're on board new devices, no there's.

H

Nothing to do with onboarding ACP is not about onboarding.

K

Okay painted yourself in the corner, but okay, yeah.

H

I mean if you have any better ideas on how we can deal with that right I mean the the whole point is try to trying to find the right weight, the right balance between security and connect right, and that's that's what the text.

K

Is trying to do and this sort of like initial thing and then all I have is a thin straw to to drink through right being able to.

H

Leverage that perfectly running Network, but basically it's too expensive, too cumbersome to basically put CRL OCSP server in each of the five hundred. You know remote branches that you have an entire enterprise, but you have basically you know in them twenty or thirty switches that basically are hopefully in the future, becoming more.

K

If you're doing UCR else- or so you end up falling back to not providing any security from ESP OCR else, because you're saying that, if I'm can't connect to the internet, I can't talk to that OCSP RC RL server, it's fancies, I'm gonna, run in an insecure mode right. No, because I can't check the validity of the certificates. Well,.

H

I'm say well, maybe and well, another way there is also text already. That is basically pointing to the fact that one way to introduce security in these environment is to work with short-lived certificates right so that, basically, you use simply the certificate expiry as one of your based security mechanisms well sure. But but my point.

K

Is done, stapling doesn't change any of this. It just makes your like your your thin straw be more useful because you don't have to worry about. I can reach a server, but I can't reach the CRL or or CSP I mean you can have the same policy choices, saying if I don't get an or CSP response in their response that stapled. What is my policy of how to operate in that case, because it could be that that end? That's a local guy inside your enterprise.

K

You couldn't talk to the server anyhow and- and that removes you as the person who might have very limited connectivity from trying to deal with that complexity. So I think that you you're not removing any policy choices, you're just making it simpler. Well,.

H

So let's say this right, so I mean the the solution for the ACP was also done a lot in conjunction with the brewski authors. Unfortunately, you know some of them are not here today, and one of the consideration was to basically keep keep the solution simple, and there was kind of the operational experience that you know. Ocsp and CR ELLs do make operations, let's say, for example, more complex than short left certificates and from that came kind of the conclusion that maybe what we try to do in this you know.

H

First version of the ACP is to try to come up with a good, reasonable minimum subset. Now, if you want to have a policy for stapling I, think that's fine right. We have raised in the certificate to add extensions and given how this policy is something which I think should be carried through these certificates, so otherwise that we have no way to provision. Maybe that would be a good. You know very simple to a three-page modification right that man basically we're saying certificates with a particular extension. They mandate the following.

H

You know for people who, like crl or or CSP and just.

D

You know I mean.

H

We already I had a lot of fight. You know for for any option that I introduced so I'm. Trying at this point.

K

H

Not any more options at this point.

K

H

If you could reduce.

K

Some things by making it simpler, I, don't understand how short lived works when you disconnected either because I can't get a new certificate right. Yes, if it expires during the night and- and you know whatever the time span is a month and then how do I deal with having a lack of connectivity when, when it expires.

L

Can't Watson.

K

C

L

C

F

Not sure if you'll remember, but in the voucher.

L

Itself, there's a leaf I think it's called revocation checks required, which is to say it's an opportunity for the policy to be specified whether or not or C, RL or or Alyssa P is mandatory, critical, so I think we already have the hook in place in the voucher yeah.

M

L

Then my second response to the peters comment is that the short live out sure if expires in mill the night. I think the intent is that the voucher is actually ephemeral and that is only being used to do the initial bootstrap. Then, once the post has been completed, it's unnecessary.

M

L

L

N

Richardson here so so yeah we had a lot of discussion of it, whether or not we would include CR ELLs in the voucher process, and we made the vouchers very short and a response to that, because, if you're not at all online, you have these other problems within just it doesn't work anyway, as for the ACP so, and and keeping the whether or not you're gonna have connectivity if your vouchers, if you're short vouchers, expire, that that's an issue and it's an issue whether you have CR ELLs, OCSP or whatever, okay.

N

So if parts of your network are falling asleep or whatever such that, you can't do this, then that's an issue. I think that that is is essentially all controllable by the certificates that the registrar issues, if it issues them with och I, can't say those words OC OCSP. Thank you stapling instructions, then that's what will happen if it issues it with CRL points, then that's what you'll do. There's lots of IPSec implementations. In the other hand, that kind of just go that's too hard, and so be it right.

N

There's quality of implementation issues and there's other things, but mostly what I would like to see is I'd like to see. If you have an island network that has no time it could have time from GPS or something with no internet connectivity. It could have time because the power hasn't gone off and it trusts its RTC.

N

Just you know the fibre was cut its back whole event. Earthquake I, don't know earthquake, not in your location somewhere else, then the hope is that if you had, unless you believe the certificate is bad, even though it expired, you might still use it anyway, and if the rest of the network has convinced your certificate is bad and they won't talk to you anyway. So I think that the in many cases operationally we're gonna have to have an experience. I think that operator is going to say.

N

I would prefer a little bit of insecurity to loot having to send a person an airplane to reset that a piece of equipment, but at least as brewski it would be a low, a person, someone who just knows how to push the button, not someone who knows how to reconfigure it right. I.

H

Mean if any of you I would really encourage you to read these these sections, where, where this is done, and the diff between 1819 should show you those places easier and if you have any specific text, you'd like to suggest there's something you really feel hot is strong about doing now. Please, you know send that to me and the list.

H

Otherwise you know, as I said, I think it's easy to add more policy options through the certificate details are just describing the ones that already exist as Michael said, and hopefully you know then, because I just really can't see that one option fits all and I think at this point in time. If we start documenting even more options, I think will never end here.

F

Okay, I have to report I have to report. We are 25 minutes later, but that's fine because, as I said, this is say, the one we give the priority for the working group could complete it. So we would like to give you enough time to discuss that. The next will be the potential new chatter and inscribing.

F

We actually did start to read up the proposed charter around nasta summer and circled on the working group list. We had one on feedback received from our ad egos worked into the official zero one, zero two rushing before the IDF in in Thailand, so it was fun to be to Lance and detailed hybrid searched the background to the proposed shortened charter. From last meeting, we actually down four rounds of refined that include in front of the ad feedback, so we uploaded rushing to the anima working group data traitor february sword and actually assess them.

F

We make two more round off refine. So now we have the latest version 0.5.

F

Actually, it has categorized the worker and work items into five classes that tongue to it just two weeks ago and for all time we have all those text open in the wiki. So that's can be same pain, everybody and we have say hopefully sufficient discussing in the menaced and in a steamy teeth here. Is they can't chatter account proposed chatter text? Do you want to go out.

H

What you think yeah.

D

H

So the autonomic networking, the autonomic networking integrated modeling approach working group develops and maintains specifications and documentation for interoperable protocols and procedures for automated network management and control of networks that are developed, built and operated by professionals. That was basically as a reminder that part two separate from, for example, helmet. The vision is a network that configures heald's optimized and protects itself. The strategy is the interim introduction of components to smoothly evolve, existing and new networks. Accordingly, animal work will rely on the framework described in draft ITF.

H

Animal reference model work not related to this framework is welcome for review, but working group adoption of such work requires explicit recharging. The three areas of the framework are: first, the autonomic networking infrastructure. Second autonomic functions built from software modules, called autonomic service agents and third intent, and by the way you just quickly see if I can, because I did change.

H

The Ani is specified through prior animal work. It is composed of the autonomic control. Plane would strap over secure key infrastructure, including vouchers and the generic autonomic signaling protocol animal will work on closing gaps and extending Ani in its components. Enema will start to define autonomic functions to enable service automation networks. It will also work on generic aspects of a si, including design guidelines and lifecycle management, including coordination and dependency management. Animal will not work on intent or machine learning and other AI techniques.

H

Without explicitly chartering, animal will coordinate with other ITF and I RTF groups, including NMR G, for intense. So this was basically my proposed lightening up with the expectation against your poor working group, chair of NMR G. If that's the right way to phrase it, okay, except of working of work, items by the working group, will be scheduled, throttled so that contributors can target them to enter working group last call after not more than four idea of meeting cycles.

H

So that was basically you know what we felt was a maybe useful to write down, because we had really a first round where there was a little bit of trouble of creating really very big and all mutually dependent documents resulting in this kind of cluster that we're still trying to finish off.

H

But most work items include but are not limited to, and this is the last slide works extending a and I, including variations of a and I deployment such as virtualization or compounding environments, information and signaling distribution within an autonomic network in I or MP interfaces management, provisioning and so on.

H

Interactions with yang based mechanisms defining the domain boundaries and membership management of the domain works regarding two generic autonomic service agents, including design and implementer guidelines for a is a lifecycle management authorization Coordination of a si brueski relevant work, including proxies enrollment at adaptions over various network protocols, variation of voucher formats, generic use case of autonomic network and new grasp extension options for them, including, but not limited to bulk transfer, DNS SD, interworking, autonomic resource management as a insurance, multi, tenant management and network measurement in the and then at last point.

H

Integration with network operation centers, including autonomic discovery connectivity to knock yang, based a si management by the NOC and reporting and reporting I. Think that should be. There is a back reporting and management AF from node to knock.

H

So this, obviously you know, is a ten-year plan and the only reason why I think we had the right scope is because we had you know in each of these areas, interesting what proposals made, but that doesn't mean that we would kind of blindly go forward and kind of accept all of these draft at the same point in time, and then, basically, you know have another big chunk of drafts going out and waiting multiple years, so the missing piece that we have and I think that's also expected not only in the data tracker, where milestones are, of course Trek, but also for isg review in the Charter itself would then be last sections with a few proposed milestones where we're hoping that we will find a good subset of documents that all have.

H

You know a separate. You know main editor to take on the work and it can tell you who can take the responsibility of you know bringing these drafts to fruition in reasonable time. The ones that we had I think well established the a sa lifecycle from Laurent. The oh.

H

Okay, sorry, the ASI guidelines, grasp distribution and the constraint join proxy, so those were the ones that came immediately to mind, but I think that's part of the discussion and then I think the whole brewski set off items I think will hopefully still have time later on today to to figure out. You know what we might want to put as candidate first milestones. Obviously you know anything that is rather new. We hadn't, even you know, checked with the working group how much they liked it right.

H

Obviously, adopting something is working group is not only that it's in charge about also that the working group approves of the document to be adopted right. So those are the two steps we need to do so this is basically the slide deck any comments on the charger.

J

Hi Burlison Chang. First thanks very much for your hard work on the Charter. This is Elliott layer again, these HR looks pretty good a couple of comments about brewski and also the I think the last line in your in in the Charter text about gating work, so I see the desire to implement class-based QoS in the in the drought, q and so, which I think is interesting. We have to I think be a little careful of head-of-line blocking in this from a brewski perspective and Michael might want to comment on this.

J

A little bit and I know that Stephan.

K

J

And Thomas.

K

J

Also want to comment: I see that there are quite a number of drafts, as you do too.

J

My view is that we should probably take some time in tomorrow's IOT onboarding session to see if we can spend just a little bit of time, mapping all the work so that we can organize a little bit around the principle that you're following here in terms of how work is delivered I would only ask that you not be too firm in terms of how many drafts you're taking on just to avoid the head of line blocking, but also I, do think this allows for a certain amount of discipline in terms of making sure the works are at least somewhat baked in order to be adopted now, I say somewhat baked, because I don't think as a working group, you want them fully baked when they come to you, you want them.

J

You want to have at least maybe an implementation to test against, but you don't really. You want to have the opportunity for change rather than having people interoperability test before you even adopt the work. So, with that caveat in mind, my suggestion in terms of filling in the blank for brewski is this is something that I, don't think you're going to be able to solve in this meeting today. I think it's probably something we need to talk about tomorrow and then take to the mailing list once we've had.

J

The discussion tomorrow is that, okay, with everybody, know about side meeting tomorrow, it's two o'clock and it's I, don't remember the name of the room, but it's in the 104 side. Meetings, vici and everybody is welcome. There's plenty of room in fact, there's more room than there is in this room, I. Think.

F

Yeah at level three notice that there's a bunch bunch of the press, key documents really submitted, but you know there are two since we want to make sure one is for now the Brisky still not free completed I mean the man draft. We would like to the working group, particularly those risky, relevant people, to review that draft and, if possible, to contribute to that draft. You know Easter rates it to be completed as soon as possible.

F

Then you know that's a time we can discuss how many draft week we can follow up and what just now tourists present there is. You know what we set up for the initial milestones and obviously we don't want to show our ist a way. Try to pour your thing at the very beginning, but you know after week gets our the Charter a new charter approved. We could have say more flexibility. You know during the working group procedure, if there's enough manager and enough, you know quality work to currently are you know, working group outputs?

F

Then we can do more work. That's fine ya know.

C

Yes, can you bring back a lone.

D

C

You bring back the Charter on the on the screen. Please I have some comments made essentially for clarification. Forget the beginning. You mentioned I work on protocols and procedures. Is it to be to I mean constraining that nothing else except protocols? A procedure can be the outcome of the working group, but maybe this is something we can improve.

E

C

You go out at the beginning of the text. Please, yes,.

C

Yeah so I mean in the in the sentence. You mentioned interoperable protocols and procedures. So if this is the only type of outcome or that we can think about other things, such as mechanisms or I'm not fan of architectural framework, but maybe sometime, we will need other types of output. Just don't make the Charter too constraining on that.

C

If you go to the next page, please.

H

Just as a common right, I mean this, this was a little bit written in fear of the same type of discussion of useless documents, as perceived by you know. At least you know, ice trees, we've seen in the past, where useless includes architectures use cases, requirements which I don't agree with, but I think we should have. You know if, if we do anything like that, that doesn't you know focus on interoperable aspects, then I think we need some some strong evidence that these are useful as far as the working group sees and what the.

C

I understand the the where it comes from and the constraint, but just mapping, for instance, to the Aiza lifecycle of work. Is it I'm, not sure it would be a protocol, but not sure you can call it a procedure? So you see I, don't see it in the mapping here. I can live with that and just I think procedures right, I think the lifecycle account under procedures yeah, but life cycle can also rely on the model and some mechanism inside okay. Okay, maybe do you want.

H

To propose explicit text I think because I, especially now that I can.

C

Maybe I will send some from the offline proposal. The second page is on the next page yeah. Just on the second bullet points. Just for clarification. You mentioned lifecycle management, including coordination and dependency management. It clear what dependency means here, because I don't understand what dependency to which to what wasn't.

H

That the term that you I was hoping I was using the term that you were using in one of the drafts that you were showing, which was you know, the dependency graphs of the different ASAS.

C

I'm not using the term that the same meaning I mean if you think about dependable components or no dependency graph right, so the dependency graph between the different components so that you.

H

Can resolve a we can again I.

C

Can make a suggestion? I think it might be misunderstood. Oh miss Fisher if you have a better term sure that I hope, but but I hope. You know what I know.

H

C

Please suggest better. Okay, then next is again.

C

Not the last bullet, just the one before you mentioned generic use cases, I, don't know exactly. What is a generic use. Cases for major use case is a use case, it's very difficult to make something generic out of a use case.

C

My question is more: like I mean if I want to go into some use cases, we have to clarify what will be the output expected by the working group to come back to there our first my first comment: if we have protocols and interoperability protocols and procedures, what's the expected outcome or form of the outcome of that can go from the use cases again, just a comment, maybe we don't need to, and you mentioned autonomic SLA assurance just for the record energy.

C

One of the initial you can both use cases was published as an RFC last year on autonomy, SLA violations, so this can be either an extension or needs to be clarified easily. If the same thing or not so.

H

I couldn't take good notes of that. So, if you have specific suggestions for the text, I think that would be even better than us trying to convert.

C

Your thoughts and write x offline can you go to the last I'm, not sure I have something just.

H

C

That's was okay. Thank you.

I

Denis McDonough's, while we are on a brewski topic, so where would you see and how would you see fitting in the more details, the various variations and extensions and what I would use it? What profiles for the brewski, which we initially targeted at the book, which didn't materialize and now it is kind of self-organizing in the side meetings?

I

How much of that you see as a maintenance and how much of that is rather central work, which can possibly be separate, and the reason for asking that if you talk about four cycles for me, this brewski derivative work, I really hardly see how that can fit into four cycles. That's much more than four cycles.

H

Yeah I mean that's I, think one of the interesting challenges.

H

The the four cycles was was just some mistake in the ground that we put in there. We can remove it right, so I mean I think we were just trying to show to the iesg that we're trying you know as good as possible to ensure that we've got more timely delivery. Then you know what we were able to do in chart around one.

H

So I think that, obviously the way we would handle this is that for each individual draught that that we accept, we would say how long do you think it takes to get into last call and when this is more than four cycles, I think what we would do is basically ask our ad at that point in time, if that's acceptable right, because ultimately, it's the ad who wants to see the timeliness of delivery of work from the working group- and you know if you right now- is an ad already see that specific work items will take longer to finish, then it's a value judgment that that should be done.

H

Anyhow right. The the whole point was just to basically ensure that the working group, without you know asking the ad doesn't take on you, know things where we can't even predict how long they take I.

I

Do understand that from your side, however, the the might be work that is both important and not necessarily directly brusque as such derivative well call it brewski derivative. So the question is where's the ride home is that animal or is that something else and I don't expect an answer from you. This is an open question.

J

J

The I think the issue here that you're hitting on Ignace is meeting time like in this room and like if we, if we monopolize the meeting time with brewski, then other work doesn't get done or vice-versa. If there's so much work, other work that's happening. Then brewski gets starved for time in the room that that's one issue and that can be solved. I believe by their two two ways you can solve that. The first is you can split off the brewski work into another working group. You always do that.

J

The second is that we can use other means for communicating like having interim meetings either virtual or real I. Think the hackathon work that Michael is doing is really excellent, along with the guys from Siemens and nxp and others I. Think that's all good stuff. So we can. We can leverage all those means communication, but I think it is a cautionary point to take into account that if we do see one of the other aspects of the animal work, starved then I think we do need to start thinking about splitting off.

J

My personal expectation is a little premature to do that, but I would I would actually be in the hands of the chairs in terms of their view and their experience as to how this is played out. So.

H

We had a lot of ideas when we had simply two meeting slots right and if we see that the work amount that we have- and there are a lot of working groups that have a lot more during the week than just you know this- this amount of working slot. So as soon as we see that we have enough, you know, work items or items, we would like to discuss to add up. I think that's the most easy starting point, even before going into any of the more difficult entrants.

H

Obviously, is always a good thing, and that can be as much self organized as you want it to, and we, as working group chairs, are always very happy to you know, support it through all the you know, things like whether X passwords that we have and whatever you know we can help to make that happen. So.

H

Does anybody know how to re-enable mirroring mode on Chrome OS.

F

Just use just use our machine to.

B

F

D

F

You needed trucker time.

D

E

B

H

Okay, but how much time do I have now as little as you can.

F

H

I'll try our.

F

Child, so here's Jeanne shell, I'm from Poway and but audio sources are not here except ocean, so this is just a short for update for the information distribution in the autonomic networking. This is the dash 10 version, so let's switch so I. Don't think everybody here fully readable documents here. So if you don't, if you don't read the document, here's a very good picture to show what is this and what do we want to do so we have a higher layer. You know autonomic service agent to do lots of automation of the network.

F

We also have the lower layer, infrastructure, autonomic, networking infrastructure to provide us the infrastructure to to transport our things. But what is missing in our observation is that we need to transfer information from one node to another node. So here's here's our target. We want you. We want to define how the information can be done over the atomic network infrastructure and especially for for not only for the synchronous communication, but also for that I'm synchronous, communication.

F

Since ITF 102, what we updated, the the working group not working group talk individual draft is that we added operations and procedures for the distributed storage and in and in the latest update. We also added an operation procedure for the even Q sub module. Okay, next page, here's just some very, very detailed things about how this information can be put in our network and can be reused later when the information is wanted. So this page illustrate that how the information can be poured in a best effort way in our network.

F

So here basically repeat what we wrote in our draft. The main main, seven main seven steps to finish the information port operations in from one node to from one one animal to another animal note: I, don't I will not go to the details every step here, but I would like to emphasize. One thing is that the grants for API part is empty here.

F

We, of course, need to map order seven main steps to our graphs in API see in our future work book next page, please- and here this page- shows how to get an information back which we actually distort in the network before I. Also don't want to go the details of the average tab. Also, we will try to define that the APS for the garage protocol. You know what future work and how to map that seven step to our cross support code specification. Okay, this is about the information put and get from mobile last update.

F

Okay next page, but these pages about our lace. It's late latest update once we have put our information in our network and how could we really notify the upper layer is a two two to see that oh there is. Such a information is ready if you really want. If you, you are really interested in such information, how could I notify the the the arbor node and services? So here we have a five main steps to do, and we also we are mapped at five, nine. Five, nine steps to grasp ossification your future work.

F

So, basically, in this Jew obsessing eye from IDF, three and four, what we did is that we put some very basic operations procedures to how to store the information in our network and later on can be published, can be published by the by the edema node and serve the a denote. Okay. Next page, please, you know a future book. Of course. Did this basic operation for searches are not enough? Of course, we really have more complicated communication, most that has to be down for the information distribution and more do so.

F

That's why, in our future, work will refer to completed the procedure for the information distribution and also another very important parts that we want to also map or to map what operations procedures to our cross four protocols so that we don't need to create any new set of protocols. We just basically reviews what we have proposed in this working group. Ok, next page, ok, and since and this since mmm this draft is many ability how to use the grasp for the information distribution in the animal Network, and it's also kind of one of the milestones.

F

So we are thinking about because the work is also gradually approach to the various very detailed specification stage. So we are thinking about whether or not you should be adopted by the working group so then so that we can get. You know most be most more speed and power and motion to deliver this work.

F

Of course, we really need the comments, and you know comments with you and reviews and suggestions from the whole working group, although we didn't receive any kind of rejection from the working group, but we also didn't receive any concrete comments from the working group, so we actually encourage the whole working group to really review and seriously review our talk and then even put questions but problems to answer that we can really improved with the walk. Okay. Thank you. Thank you. um The church, won't, you know court option for this meeting because actually there.

C

F

Market Oh miss miss wait because that's just our proposals for the new instance.

C

F

So maybe next time you should not.

K

F

K

Do knowledge they.

F

Work, the working group participant to rate this draft, of course,.

C

F

We said it's actually the extending of the grasp exactly.

C

F

So it's in they can't charge also should be in the proposed new charter, yeah yeah yeah yeah. Thank you. Yes, okay thank ya.

F

H

Try to change I read the documentation. The documentation for Chrome OS was wrong, so I.

A

F

But he'll create initial fool next chair sitting here.

F

Okay, so we have the exciting, and actually we are now almost 20 minutes, late and I'm decided to cut off the last individual draft. So we just a minute right, so you can honor.

N

Our tried so document status on brewski, so Max and I have met almost every Tuesday and sometimes Tuesdays and Thursdays since last ITF, forty three hours and you saw the list of tickets or about sixty three of them and next slide. Please we got them all clothes.

N

We had three two large reviews that happened just before ietf 103 and one that arrived sort of just at the after it, which was from the rest house Lee, and he may know him more as a security guy than an IOT guy. So there's lots of overlap and we put at the 18 I guess in January ish, with kind of just kind of keep people aware. So people could, you know, maybe get closer to getting the changes, understood and 19 was sent out just on the 9th or something like that next slide, please.

N

So those links go to. If you want to read all the reviews, if you want to see all the stuff there's, the diff and I posted the message.

N

If you want to see the issues that are there in most cases, the issues, the texts that fix the issues as visible as in github as the commit that fixes it there's one or two where you know we screwed up and didn't put the number in it was one or two or you me see some checks, some two or three two or three fixes and one thing, but mostly it's just their.

N

New sections that were added particularly at an applicability statement just make it clear that when brewski is applied in the ACP context, what you need to do we had a lot of statements like that spread throughout the document. We mostly left them there and then we also collected them into one place. We added a large I think it's three or four page privacy considerations section. It deals with stuff that is revealed either by brewski during the protocol or is revealed to the manufacturer by by running the protocol.

N

So there's some things that an observer, a passive observer by eavesdropping, can see things. So if you use TLS 1.2, for instance, they can see your ID ev ID going across the wire, which means they know who issued it. They know what your serial number is and stuff like that until that's 1.2, that's just the reality for certificates over the wire, not a lot. We can do about that TLS 1.3. It does crypto, then authentication with certificates.

N

So it's really good if you used to that's 1.3, but we don't mandate 1.3, just we mandate, TLS use good TLS. So as people switch to 1.3, that's good, but then there are things that you would reveal revealed to the manufacturer anyway, and you need to because you're going to get a voucher back and there's things like that. The vouchers are never visible to a passive observers but clearly are visible to the manufacturer that created them, the Registrar that processes them and this kind of stuff- and we don't consider that really a privacy violation.

N

That's the part of the feature there were a lot of discussions and long threads about. How can the manufacturer keep you from selling your used equipment and to things like that, and we have a section on this. It was originally called gray, market equipment and I. Think it's now been switched into split up into a couple different pieces there and there's things.

N

For instance, you know and where I live in Canada you know some equipment is cheaper if you buy it in the US, so you buy a new ass to ship it to the thing you drive across the border. You pick it up, you do it and you call support and they're like no I'm, sorry, but your gateway laptop is not supported when you call from Canada right it's a common occurrence in a lot of markets where we call cold gray market. It's not that you stole it.

N

It's just it's not supported in your market where you are running it, and so that's the kind of thing that could happen and and brewski essentially automates the manufacturer learning about you doing this right, because your IP address when you register it is clearly not in the place where they thought you were running it. So is this a new problem? We say no, have we made it automated? Yes, so ok, you may have some opinions about that right, but it's not something that fundamentally is different.

N

And fundamentally, if you're running, you know big piece of forwarding engine and you don't trust the manufacturer to provide you working firmware, then this is not a new problem. You are already getting. You already have to trust them for working firmware. So if that's the issue that you know then I don't know, maybe you should be building a company that makes verifiable router firmware instead of worrying about this next slide. Please.

N

So there's been, as you've said, there's lots of people interested in doing brueski. It was a surprise to me that the thread group has adopted it. We don't, unfortunately, have official liaison with the thread group.

N

There are some people that are members of both I've been trying to get some kind of formal process to go back and forth, and so I have to say, ask details from them, because I actually don't know, even though I'm working with people that do it I don't actually know what they're doing that um a bunch of implementations have been out there and we actually came upstairs from our third in-person session, where we're in a room.

N

There's a couple people here that are there doing that I understand dots working group wants to use brewski I, don't still don't quite understand the the the exact use case. I learned some things that are surprising me today in an email, but there you go next slide. Please I repeated the terminology, so I in case you haven't seen it because I think it's used to keep repeating until you do it I forgot to bring my rubber ducky.

N

Have it downstairs, you want to see one next slide, please we considered and decided not to remove the unsigned pledge, voucher request. Interoperability testing said that that was the easiest thing to do, and we, and so it was a surprise to see it from certain places. When the pledge asks for a voucher, it may do so with an unsigned request. It's an option. The Registrar always signs its requests to the masa and the results are always signed in all the way can be verified all the way back to the pledge.

N

The only time you don't forward in the pledges signed or unsigned voucher request to the masa for sure is when their pledge is not turned on, and you are doing an offline request. Peter you're, having problems deep, yours, frowning and you're having chrome, seeing or just I'm just I'm, just wondering cuz you're yeah.

N

Oh there's something happening on the screen: okay, I'm, just wondering if it's misunderstanding, there's like there's words that are just wrong or oh and it went again: oh I stepped on the cable, maybe okay, all right so yeah. It's really fuzzy on my screen too. So there's something really up.

N

So we don't actually upon consideration. We realized that that, as I was trying to implement as well some things that that there is no vet. If the pledge sends an unsigned request that the only thing in that request that has any value at all is the nonce and it needs to be sent by the masa to the registrar to the masa and if you are sent asking for a nonce list voucher, in other words, one that doesn't expire, that's for a pledge, that's offline, then obviously you don't even need to talk to a pledge.

N

So then the question is: was there any value of ever supporting an unsigned, voucher, request? Okay, we feel like it almost has. There's no there's no point at all to it right and we wrote it as a compromise. You know in the early days of the document, believing that this protocol would be useful to constrain devices that had to do a small amount of crypto. Well, if they're doing, TLS or DTLS or IDI hawk and they're validating the voucher, whichever form it is, it is in CMS right now so asn.1 as well or in Cosi.

N

So it has to do some crypto anyway, so then the question is for an online pledge.

N

Can we just get rid of this option, and the corollary is that we wrote that the constrained voucher document would only support unsigned voter requests, because we thought crypto was hard and so I also think that that we should remove one or the other in that case and I think it should be the unsigned case. So I'd love to hear from the working group about this and I think this might actually the last slide than my new slides, yeah.

L

Hi this is Kent Michael I'm. Sorry, can you just be more clear about what is the decision? Because there's a there's question: no you're you're, saying things and the framings questions. Yes, it's.

N

Very clear what what actually is the decision is, should unconstrained brutes brueski, that's a question asked all right. What is your view? What does I believe that we should remove unsigned pledge requests from brewski I believe that constrain brewski, which uses constrained vouchers, should always how so always have signed. Pledge requests as well and I had a different view. Six months ago, okay,.

L

To restate that you, the the consents or they you're thinking is that vouchers should always be signed. Voters.

N

Should always be signed, that's a good way to put it yeah. Yes,.

J

This Elliott, so I I, agree, however, I think over time. The form of that signature may need to vary I.

N

Totally agree like we can, you know we have CMS, we have Cosi, we could have JWT if someone would like to have something between. We can have quantum crypto alien stuff doing whatever my melds, that's okay. As long as it's signed.

I

So, what's next, with this document, you mentioned your issues list is that completed now, I've done a ad review for version 17, which is quite radically different from what it is a 90 yeah. Do you expect 20 be posted really soon and no major changes afterwards? Do you need more time? What's what's our studies.

N

I

N

This one that are talking about now it involves the leading text, not adding any and.

N

Like for paragraphs or something okay, um the diff from 17 to 19, which I also I, did post that as that in the message. It's it's a it's a, not a trivial death, but it's actually I thought it actually looked quite well. It actually I found. It went quite well to me to say yes, there's not actually that many changes. The text that has changed is mostly in response to clarifications that people have asked for or no changes on the wire from these changes. um The exception that we remove unsigned pledge, requests.

N

So from that point of view anything or any thoughts, I, don't have or any code that anyone's written is unchanged. I would suggest, please start to review now. If the working group concludes on the mailing list, that this is the good idea, then we'll cross that text out and post 20, but I don't have an intention of host 20 this week or next week until someone says that we have clear consensus to remove this. Okay.

I

So another point on this: due to the amount of changes which went in since elastico the version which was last call's. This will have to be another last call: okay, fair enough, so 20 anyway, we'll have to materialize at some point of time, and probably 20 can be the last call version. So, okay, so.

N

I would be very happy to do that if we do a two-week last call then, and the conclusion from this is to remove it.

N

Then let's remove it and so we're gonna get the cable fixed for those who are remote and that would be great I did do unicast the three reviewers with the with the updates I, will I'm going to pigeonhole some of them in the hallway tomorrow and make sure that they really saw the updates and I'd like their positive acknowledgement that they're, okay with it I mean there's a lot of issues that were opened and so yeah. So great. Let's we'll working group last call it again. I guess: okay,.

N

I another slide that I sent you guys but actually realize it repeats the slide. I forgot. What's in my slides, you know it repeats the slide about interoperability. We did. We have had three fair, hairlines and probability sessions. The first was late November after IETF 103 next was in Zurich at the beginning of February, and the third one is happening right now and I think we're going to have I think we're going to have may have some more.

N

They may or may not be on in person, we're trying to find some compromise between working remotely on your time zones and being together for too long a time. So that's it. So if you have code out there and want to participate, then there's a there's we doing it online is totally feasible and I'd love to have more more things. Doing that.

D

N

Vouchers, yes, you ready yeah, that's the right! It's not on my screen! Oh there we go all right so next slide, so we adopted it last spring. The both the document got finished last summer fall and then it got neglected to the point where it expired yesterday morning, well actually last week, but the system doesn't remove it.

N

Till yesterday morning we posted yesterday there are four or five comments on it from ESCO, one of which you noticed the voucher request example and voucher example were swapped, which is hard to see unless you look at the SID numbers.

N

So the sign is Cosima.

N

Tours and we're working on some better examples and.

N

That's it next line.

N

So we agreed essentially on the mailing list. I think there was a lot of discussion back with, though, with whether this was the constrained voucher document or the constrained voucher and constrained brewski document that was unclear to me. What we had. What we had agreed to do. The consensus was that it is going to include both I believe that some of the burski end points to be constrained are are under specified in the document. So we need to include that a little bit more.

N

We want to include examples that include the private keys so that you can run it through your software, validate that you get something identical for what we got, or at least close enough with with, given that ECDSA needs, a random number I will put the round a number into we dependent on the core working groups, CID work, which translates yeah Mille to see Boer using integers instead of strings.

N

We saw at least an interoperability. We sought one at least one implementer, who translated the Jason to C bar using strings, in other words missing. The whole constraint. Voucher point is like okay, that's not exactly what we said, but there you go so at this point, the tooling, to make the CID values out of the yang document is unstable. You run a different versions on different people's computers. You get different numbers, okay, so that's an issue. So what we've actually done is we we've said? Okay, that's really nice, we've done it once they're wired in.

N

We don't expect them to necessarily be reproducible from the same process at this point. So that's unfortunate from a core working group point of view, but that's probably the best way for us in general that whole work needs some something to do. We need to kind of send a message to the core working group to get your stuff done next slide. Please we an allocation excuse.

O

Me yeah, let me worry you only the bit more: oh yeah, the young specifications and young support specification and specific a which we actually are using are now being this curved to discuss its core I hope that they agree about the document such that 0 will go forward. Okay,.

N

Yep, so that's better, so better news, I guess! Ok! So at this point we've taken some allocations, they're allocated from a mega range. The idea was that I Anna would give out to various. I anna being a fairly expensive allocation process for implementers would give out ranges of a million numbers to other entities that would parcel them out in groups of 50, one of which was a reference. Mutation called commute space and they gave us those numbers that are shown there so we're using the numbers.

N

We don't know how to allocate them properly, and I guess this is something you have to go back to the core working group, whether they're gonna. Let us basically put our numbers in or they're gonna tell us, you lose your ninernet Draft go back to scratch. Okay, so that could screw us up at least a little bit, because we'll have to fix code and next slide that I.

C

Think is last line. Yes,.

N

There you go, that was a major issue, so that's gonna! That's going to put a hiccup in getting a document. You know out the spaces that that dependency on the brewski dependency and that stuff I noticed that CD DL is now in the RFC editor queue with Ayana step. As of yesterday so I we might actually unwedge that hole. Those other documents by the end of the week, I think so I might be good. Thank you.

O

Keep it under seven minutes older, oh.

O

Okay next slide: please we have whiskey, which has just been explained: she's, HTTP and TLS uses HTTP and TLS. We want to replace the circuit box, he makes it adapt at all to co-op and DTLS. Please come on, oh no, it was based on an earlier draft which has been published and has been. This will become one all about three years ago.

O

Okay, so what we have a graphic explanation that we see the pledge which has a lowered glocal discussion, is the circuit proxy in Brisky and then disgustful circuit proxy on the global network to the domain registered. What we want to do is replace this circuit proxy by the join proxy. That's specified in this draft such that you can talk with the pledged link locally and also global whistie register by using coop DTLS.

O

So far, so we have two ways that we want to do that as a stateful and a stateless like with the form a draft by kumar, where we have a stateful where we have the fetch discussing mister join proxy, did join proxy, remembering the link local address of the pledge and then doing the global discussion. Mr. registering a register sends back a message and then the join proxy says: oh I know where this has to go to and recovers the address and sends it back to the pledge, the other one. So there is no.

O

The Detailers encryption has used at the deflection at the domain registers site. The join proxy is not involved at all and doesn't know what goes on yeah the same one obviously same so we also have a stateless one where the pledge, since the the link local to the join proxy, the join proxy doesn't store it but makes an header image. The link local address is stored and then sends it on to the register domain register, which remembers that was this other address since it where the joint proxy says I know where the center to so.

O

These are the two. Once we don't know those have been asked for, so the draft no actually specified both. What's the current discussion is that, when you sent between the joint proxy and the domain register, how should you, what kind of format should she used to store the link local address? You use and Heather and co-head of placing I had been thinking of doing it using the new the co-op formats, so you stole in the in the in the in the payloads.

O

However, for someone for implemental think that getting that's all changing the payload is much more complex than have profiling. Other Heather I'm, not convinced so we are actually discussing it. I have here a small overview on to show that actually, this fits in an whole a series. We have the Brisky which has been discussed before we have the HD co-op s, which is actually discussed and goes to virgin group, has gone through the red glow Brasco in ace, which tells you how to use go up to do the est processes between pledged and register.

O

Then we have the voucher, which has been done here amidst LCD, how you get the confidence from the Massa etc, and we have the constraint voucher, just discussed here where we have some other formats security formats which are added. It uses the furture and then now we have to constrain your poxy I hope it can continue. It anima discussion, which uses also cell born. Maybe use multi-part contents draft if you're not sure about this for a moment, and it extends this Biscay vista constraint join proxy, any state corpus, so the whole thing nicely fits together.

O

No so so we have to update the example palos the same, which is true for the constraint foyers. You have to improve the discovery text is in its sparse compared to what should be expected, and we really hope for commands which are really appreciated in this context and major question: what about anime.

H

Here you know, just as an individual contributor I think, to review all these constrain documents. It would be good to understand. You know what the typical type of constraint devices are, that the solution is targeting rights.

C

H

That context, so because it's hard to you know, figure out the applicability without knowing what it's meant to be applied for us and I'm, not sure. If any of these drafts has a specific good section about that or how would we deal with them with that? That type of the.

O

Tries to extract from that, and it actually says you look here: constrained devices use go up and DTLS. How can we handle that in the context of Brisky I think that's the the level at which the traps, so we don't go any below say what is the six we'll open structure of the message? We do not do that? How large may be made the processor be. That depends on the implementations of the you. Don't discuss that.

F

Christine, yes answer: question I mean tea beans. There are so many work proposed irrelevant to Brisky proposed to animal working group, and you know we a proposed to including those works in the next charter. But until you know we get that approved, you know still in there, yeah.

O

Comment, but much of the work done for the joint proxy is done in collaboration. Is the constraint voucher? Yes, so this actually goes together. If the constraint for examples can be made, they can be made for the constraint proxy. So there is a lot of synergy with this those drafts. So it's not just an extra branch of work in nicely fits together. So if you, if the work load, is any consideration, I, don't think you should bother too much business. All.

F

Right. Thank you. Thank you for clarity,.

O

F

N

Should turn my hat sideways of it to change projects so I've been working on a project involving doing IOT firewalling in home routers and a certain amount of eventual IOT enrollment using brewski and mud files to provide the process of a lot of the security, and one of the things we want to do is not involve passwords ever on the home router for any of the moving parts. Next next slide, please so next slide, please yeah! So that's that diagram. We have a video. You can see. That's a smart toaster.

N

It's got an iPad attached to it and.

N

We've done this talk and you can see more about what we're doing. If you want to go to those links next slide, please. So we have an app. It runs in the phone talks. Api does things about mud? We want to fennec ate it with a TLS client certificate. So we would like the phone to be enrolled into the registrar that is running on the shg, the secure home gateway so effectively. We want what brewskis and anima as acp wants for every node, which is a identity, a secure identity within the domain on each device.

N

The catch is next slide. Please well, I got a lot of page numbers are broken on the bottom. My interface is tinder, like um you know you like the device, you don't like the device, you like it a lot. You hate it. So up-down left-right things like that. So up means you know it's a PC. Give it give it infinite access right means, I, like it and but use the mud file. Left means you know, get rid of that vacuum cleaner. On my network, okay down means it's broken. Please get put it in quarantine.

N

Next slide, please, um sir I've said that sand roll a smartphone into a PK database in a registrar assumptions. The router has a QR code on a sticker attached. The smartphone has LTE connection or can walk around and find another Wi-Fi somewhere else.

N

Okay, the Reuter itself is probably the one that accesses your internet and especially if it's pppoe DSL kind of stuff and some other things it doesn't have any internet yet until you connect to it until it what's the password that you're supposed to use for the pppoe, so no passwords in our system, but the ISP of course still wants one for pppoe and, as stefan tries and the next thing we'll talk to you a little about his requirements. It might be that there is never any internet on that device next slide, please.

N

So how do I do that? How am I going to do this I need to not only don't need to enroll into a registrar and you tuned to roll in a registrar for which I don't even own? Yet, okay and so that's sort of the the question- we're not just bootstrapping the phone, which would be a pledge, but we're bootstrapping the router, which in some sense has to be a pledge as well. So it's a kind of recursive application of risky next slide, please. So this is what it looks like what we're proposing.

N

You know in all-in-one, step kind of thing and there's another slide. I'll show you there next slide, please so smartphone is the client and afterwards, and we want to do basically, once we have a connection established.

N

We want to do an enrollment, simple est, enrollment, just like the end of brewski, and we want to then we'll have a connection and a pinned certificate in the router for the phone that says this is the administrator certificate and everything's good next slide, please so, first, wherever this draft is called smart pledge, because it's a smart phone and it was pledged- and on discussions and explaining to people, they said hey, this is really confusing because the devices to keep changing roles- and so it's not the pledge anymore so start doing that, and then the other jacques letoure suggested that kkuk link was the right word and he says in his Gaston French accent and it sounds very much more much more rugged than I can do it, and then he provided a nice picture of the two glasses clinking which, if you can't visualize the sound I, hope you now can't so we're at the document, and we took the tea out.

N

I, don't know why there's a typo the first time and I decided I would keep it that way. Smart clink, okay, next slide, please.

N

So one of the things is that the manufacturer still would like to maybe keep track of who the device was registered to from an abstract point of view and might even want to further have the owner go through some kind of online registration process right, so you go to register your new fancy washing machine and they would like some details with you from you about who you are where you live blah blah blah.

N

Would you like service plan this, whatever okay, so there's an opportunity included in this to basically do an oauth2 process where you would sign up to the manufacturer or do the whole create new account or whatever it is we're not getting involved with that? Just saying you know insert complicated stuff here, so that's why there's a transit transaction that turns out to be a little bit. Weird next slide, please QR code!

N

Well, we don't want to invent your own Wi-Fi lines, release this device provisioning protocol and it's really cool and I'd love to just use it, but it uses 802 11 management frames which I don't even know how to do from Linux with root right now, but I'm sure I can't do it from an app on an Android or iOS phone Google or Apple will have to do this provide api's, and it's not clear to me that it's in their interest to do that so I hope it'll happen. True, EP new!

N

Does that there's a lot of discussion not yesterday in mu but I'm, not really and building in a back-end or a system like that for the home and I'm not really interesting? Having a cloud do that so I? Don't really know how to do that. So kind of didn't didn't go with that, but all using QR codes, so I stole the DPP QR codes, specifically in the hope that eventually some of protocol on describing will either be replaced with DPP or will facilitate an update to PPP to become DPP next slide.

N

So I said that next slide so can I have a clicker yeah, okay,.

A

N

Because I want to control, it goes next slide, so so the the first the device is, the pledge. I call it the adolescent, registrar, meaning it hasn't grown up. Yet, okay, that's not the right one.

N

There we go okay, so so don't, okay, so so the middle, the middle device is which would normally a registrar, is the phone okay next and we have a Massa and the initially. The router is the pledge with the duckling next slide and they register the phone appears to be register I like good, okay, next line, so we scan the QR code. It tells us a bit a bunch of information public key of the a are some ESS ID information link, local addresses of the of the thing and the address of the Massa next slide.

N

Please so we generate assert self signed certificate and next slide. We send it to the to the Massa. We say: hey I'd like to be introduced, it does some Roth to stuff with F is appropriate next slide. Please, and he gives us back a certificate. A sophisticated NASA would give us back a certificate, and you know that it really had done and maybe validated my name a lot and whatever and the stupidest NASA echoes back the self signed certificate. I gave it and says: yeah I just use this. Okay, probably recording my public key.

N

Okay, so I go on connect the same kind of stuff and I connect next slide, please, with an encrypted nonce that I send by EC, yes, which is a way of using encryption with ECDSA to the public key that I got off the QR code, send it there the device decrypt that which proves that he has possession of the private key and sends me back. I asked for a voter request, so normally the voter request is posted to the Registrar. In this case the Registrar is asking.

N

Could you send me a vote to request, so he sends me a vote to requests the nonces in the voter request. As an extension of the register, can the phone registrar can check it make sure it's the right device hasn't spoofed on this open Wi-Fi network and we send it to the register to the masa as before. Next slide, please we got a voter back next slide, there's the voter and we send the voter to the AR.

N

They are checks it using its trust anchors as exactly as before, not in in brewskie, and we get a reply with the provisional state, inflammatory and we send there were telemetry up next slide, please. So at that point we now have established a trusted connection between the phone and the Registrar and now you'll see that the phone and the Registrar have swapped places the duck, and the customs guy have stayed where they are so now.

N

The phone is in fact the pledge and the Registrar is, is in fact running as a registrar and he's grown up, he's no longer in adolescence and we do enrollment, we get a certificate and that's basically it and then we do something specific to configure the router, some api's or whatever. But now phone has a TLS client certificate. Registrar has a idea of ID the to have trusted each other, and you can now do whatever it. Is you like to do with your new device and next slide? Please I think that's lost.

N

We have some stuff, we delegate names to the to the router. We put an idea of ID on it. We get a certificate under that name, but the your way of the router in the DNS so that everyone else can invalidate it correctly and that's part of also what we're doing next slide. Please and it doesn't roll belong in anima, doesn't belong at home net I, don't know where to bring it, but you know please, like me, can we did.

H

For the matter of time, not two questions: now we just got less than ten minutes and I still want to do the.

A

Yeah excellent.

D

P

Stefan, please Simmons I try to be fast as well, so we we have been involved in risky implementations and what we figured out is that risky is applicable in synchronous scenarios, but not really in a synchronous scenarios as internal scenarios. Next slide, please are scenarios where we might not have a string stringent network connections, so they might be temporary, no online connectivity, either technically a reasoned or by policy. In a second stage. There might also be not an on-site PKI functionality available.

P

So this means that we have to store-and-forward certain information in the domain and then forwarded later on to a PKI which may reside on a back end.

P

So that means if the domain itself doesn't feature something like a trusted component, where we store the information from the initial authentication of the pledge which has been done on the TLS link in the EST link or in the TLS link of the EST connection, then we we run up in a problem when we forgot that information further, so the certificate signing request to the PKI component that resides on the back end further ones are use cases where we have multiple TCP hubs.

P

So that means we may have much about TLS verbs and on the place where est ends. Typically, the authentication ends, and you have no means of forwarding that authentication also pledged further on to the place where the authorization to session for the certificate signing request is being made. So if we next slide, please, if we look at Brisky- oh that's the old slide, sir, but doesn't matter specimen.

P

So what we propose basically is to utilize self-contained objects for a certificate request and certificate response to be able to store those messages, either in the domain itself or to be able to process certificate.

P

Signing request further on to a PKI that resides in a back-end Network, as you can see here, I basically changed the picture a little bit, so you see that there is no PKI component in the in the domain network itself. So that means we. We store some information on the domain registrar and for what certification request further to the PGI, which resides in the backend.

P

What we assumed here was that the PKI, so the registration authority is responsible for doing the authorization of the certification action, so this is typically being done using an asset management system or an inventory management system which also resides on the backend in most of the industrial applications. So that is the reason that we would like to support a self-contained object for certificate, request and response message just to basically be able to do the authorization of the certificate signing request in the backend.

P

This doing that in a self-contained way. We would basically do it in a similar way like we have the voucher exchange at the beginning, so the voters also self-contained. So we stick to the same model though, and it was also support, invent an out-of-band certificate request and response messages. So inbound means that we can use existing trouble codes like like other industrial protocols that may basically piggyback doesn't promise or the self-contained certificate signing request object, or we can do it in a way like it is specified here in Brisky as such.

P

So if we have the self-contained object, then we can also combine it with the voce exchange itself. So this is a dotted line on the right hand side. So we could view basically it's a certificate signing request together with a larger request and let it process by the by the back end, actually under the assumption that the deployment domain itself doesn't have a direct connection to the internet and thus doesn't have a direct connection to the NASA next slide.

P

So the next step here would basically be to define basically more outline the awesome promise certificate enrollment using the self constrained object.

P

So that means we need to define and next steps the self contained a safe constraint approach come up with a young model for that which should should be protocol agnostic, and that also means it should allow for using existing protocols. So there are already existing enrollment protocols that support self containment.

P

Some of them are way it's a new based and Mike I know you don't like that really, but anyway, it also leaves the option to come up with a different encoding scheme. Actually, if we have the self contained object for the was a certificate request, response exchange, and we may think in a second step to couple the certificate exchange with the voucher exchange and the question would be- is a working group interested in network well.

H

It will erase that question on the list.

D

H

Presenter two presentations and talk: that's correctly.

J

Okay, is there any there's? No good? Okay. Can you hear me, but next slide all right? This is basically a quick overview of how how we're planning to do brueski with wireless. This is only part of the problem, but here's that your average brewski flow you've all grown to know and love and you'll notice that at the front here, you have something like discovery with mdns that could just as well have been grasped initially and initiate TLS with HTTPS could have just as well been yes, yes to you over co-op problem.

J

Is you need an IP address for any of that stuff? You need to have l2 connectivity for any of that stuff. Well, that's a problem in 802 11 next slide, please!

J

This is just the next phase keep going so what we've done is we've taken both brewski and ESD and crammed it into a neat method and by cramming it into a neat method. You now have a means to communicate with at least the registrar and through the registrar, the masa and you're doing this through Ipoh l, 802 11 frames isn't that nice and you can use e for other things, which is also nice. Ok, next slide, please.

J

So we got a lot of stuff to address. Something really happen to the fonts here. That's that's all broken. Let's see here, we don't know they're there. A couple of errors in the current draft in terms of the flow section, 6 I think. Has it right section 3? Has it wrong so the way we have to fix this is to code.

C

J

Code and which is what we're going to do in the next couple months, we also want to incorporate the work. That's the fun just talked about, because we think that's important, which I call the. If you go back to Jerry Seinfeld episodes, there was the Soup, Nazi and I call this the know super.

J

You come back in two days option, so you can handle asynchrony and we need to address the offline use case as well, which I'm not quite sure, is perfectly solved by what Michael just presented, and we need to really actually delve into that and we still have a SID selection problem which we need to tackle. That is primarily a problem when you to thousands of these things in the center of Tokyo, so it could be something that we can solve in.

J

You know in a phased manner, that is to say, we probably may not have to solve this immediately, but it's something that we probably do need to take on and when it comes to brewski, particularly the online methods. This 2,000 CID problem becomes a royal pain in the butt next slide. That's it! Okay! Now is that there.

H

Was a second one was our second one brewski? Is it okay? All.

D

Right question see no.

H

So I think definitely I think the most important part. Please folks, you know, requests a lot of time for these new things next time around, so that we really make sure that we do get you know either. You know three hour or two two-hour sessions right that we can actually spend good time on getting these enough reviewer discussion in the room so that we can have you know a better adoption call, because right now we hunted off any hour because we're still trying to finish up on the Charter but next time around.

H

Hopefully that would be a really good time to have long discussions and we'll get more time.

E

J

Not just to response to that really quickly. This work was not ready for adoption. It isn't ready for adoption was shown to emu as well, and some of the organizational discussion is does that belong and emu does it belong in here and that that, as a matter of where we need the experts to be honest, yeah.

F

Sure so, hopefully we will have our new chatter approved before next a calf meeting. Then we have we're in better position to serve the in the community, so I declare to close this session and say oil guys in Montreal right. Okay, thank you.

H