ANIMA WG IETF-105, Montreal, Canada Chairs: Toerless Eckert & Sheng Jiang Minutes by: Bing Liu (Session I), Guangpeng Li (Session II) Session I: 10:00-12:00 Tuesday Moring Session I, Duluth Session II: 13:50-15:50 Tuesday Afternoon session I, Centre Ville ************************************************************************* *****************************Session I*********************************** ************************************************************************* 1. WG Dash - 5 min 10:00 - 10:05, by co-chairs ************************************************************************* 2. Autonomic Control Plane, by Toerless Eckert draft-ietf-anima-autonomic-control-plane - Detailed discussion on "Cert Renewal" issue: Michael didn't understand the attack model during EST server certificate renewal. Toerless explained the attack was that some point in time a client figures out that the trust anchor certificates are expiring, so he's renewing the trust anchors and if then he gets randomly to some attacking EST server on the ACP. Michael thoughht the attacker must to be a compromised device that already enrolled in the CA. Not sure what can really help on preventing this attack. - Detailed discussion on "Encoding of ACP domain-information into Cert" Michael commented that CA softwares normally are very conservative, that it untolerant without CSR attributes. ************************************************************************* 3. GRASP API, by Brian Carpenter, draft-ietf-anima-grasp-api [Sheng]: Need volunteers to review before WGLC. Michael Richardson and Guangpeng Li promised to review. ************************************************************************* 4. Re-chartering Progress Report, by Sheng Jiang New charter text has just passed IESG review. Last change has removed obscure words on the scope. There is still external review procedure before the new charter go into effect. https://datatracker.ietf.org/doc/charter-ietf-anima/ ************************************************************************* 5. Autonomic setup of fog monitoring agents, by Carlos J. Bernardos draft-bernardos-anima-fog-monitoring [Sheng]: (speaking without chair hat) what would be the fog node? What's the difference in perspective of network node? [Carlos]: May be and end user device, e.g. the mobile phones; or the devices at the edge like an acess point etc. I agree it's a generic concept. [Bing]: Did you find requirement of using GRASP over UDP for the nodes? Since TCP normally is not a good choice for IoT enviroments. [Carlos]: This is something we wanna investigate. [Brian]: The thing about UDP for non-Discovery and non-Flooding, we hit the problem the UDP is an un-reliable protocol, there are two ways to fix that: 1) put the reliability into GRASP, which is horrible thing to do; 2) require that any operations to repeat if it fails. It's an area where we actually need some feedback before we do a work on it. [Toerless]: (speaking as an individual) I'd love to talk to you how it uses the ANI. To get back to the UDP stuff: if the data being transfered using GRASP encoding, but not necessarily over the security protection, it can be just over whatever forwarding plane exists, with UDP encoding or not. [Sheng]: (speaking with Chair hat on) need to think about what is the re-usable functions in the perspective of applications. [Bill Atwood]: (replying to Toerless' comments) maybe we can stop thinking how little we can secure and thinking what do we absolutely not want to secure, and everything else needs to be secured. ************************************************************************* 6. Information Distribution in Autonomic Networking, by Bing Liu draft-liu-anima-grasp-distribution Michael Richardson and Laurent Ciavglia volunteered to review. ************************************************************************* A very brief discussion of the the re-charter approval time between AD Ignas and the chairs. New charter is expected to be approved in August. ************************************************************************* 7. Guidelines for Autonomic Service Agents & Transferring Bulk Data over GRASP, by Brian Carpenter draft-carpenter-anima-asa-guidelines draft-carpenter-anima-grasp-bulk [Sheng]: dependency issue with Lifecycle draft, we'll need Laurent to continue the work. [Laurent]: I hope to go into all the details, yes. [Brian]: We'd like to adapt the texts regarding to Lifecycle and Cooridnation in this draft, to not cause difficulties with the dedicated drafts. [Michael]: (for GRASP-bulk draft) as a recall, this was initially for Intent? (Brian: we don't use Intent now.) So, we need a backup use case for why we need that. [Brian]: This is about when we'd like to use it rather than a file transfering protocol or file sharing protocol. I agree this is not urgent. [Sheng]: I think you need a "MUST" use case for the work. ************************************************************************* 8. Scenarios and Requirements for Layer 2 Autonomic Control Planes by Brian Carpenter, draft-carpenter-anima-l2acp-scenarios [Sheng]: (speaking as an individual) why transmition of IPv6 a "must"? [Brian]: It's not a requirement on the network except for the support of multicast, which doesn't need to because it's level-2 multicast. You don't tell people they have to buy an IPv6 router for this. It's just a (virtual) wire capable of carrying IPv6 packets. [Sheng]: So this is the requirement on the nodes. [Brian]: Yes. [Michael]: You need TCP socket? [Brian]: No. [Sheng]: As an individual, I hope it is non IP-dependent, neither IPv6 nor IPv4. For WG, I concerned whether we are allowed to do L2 stuff. [Michael]: MacSec, which is an IEEE protocol to do key management, might be a solution to consider. [Toerless]: ACP doesn't rely on bridging; but for the L2-ACP, if bridging breaks, the L2-ACP also breaks. [Ignas]: From operational perspective, on some ethernet networks, you cannot assume it is always bi-directional communication. [Bing]: Speaking as a co-author, my perception of the IPv6-dependency issue is that, rather than requiring IPv6, it might be more precise to say we need something can provide autonomous L2 connectivity and transmittion of packets that could be secured and seperated from normal L2 data plane. [Ignas]: (As AD) What is the problem to be solved, that other components couldn't do. [Brian]: ACP's complexity. [AD]: Simplify the ACP itself, a light-weight ACP? ************************************************************************* *****************************Session II********************************** ************************************************************************* 1. WG Dash, by co-chairs ************************************************************************* 2. Bootstrapping Remote Secure Key Infrastructures (BRSKI) by Michael Richardson, draft-ietf-anima-bootstrapping-keyinfra No comments. ************************************************************************* 3. Constrained Voucher Artifacts for Bootstrapping Protocols by Michael Richardson, draft-ietf-anima-constrained-voucher [Toerless]: Could I assume that we're trying to target getting this over to IESG for IETF107? [Michael]: Submitting to IESG right after 106, so WG could be finished by IETF107. [Sheng]: I don't think you could get into IESG and get out of it during one IETF cycle.(ACP may be four or five IETF meetings) [Michael]: I don't know. Longer documents are harder to deal with. There should be no political discussion. I hope that will be easier to discuss. [Toerless]: So it won't become RFC before BRSKI RFC normative dependency. [Michael]: That's the point. ************************************************************************* 4. Constrained Join Proxy for Bootstrapping Protocols by Peter van der Stok, draft-vanderstok-anima-constrained-join-proxy [Toerless]: If there's a quick explanation multi-hop coap discoveries that working is that? [Peter]: You can do 2 things. You can send multicast this coap discovery which is discouraged. The other thing which you have resource directory in central, you send in unicast and send you back all the devices which have this particular service in its memory. [Toerless]: There's dynamic registration for the registrar with a directory. [Peter]: Hope this being in the new charter. [Toerless]: It is on the list there. The adoption could hopefully start before 106. How much work would be left from that point on? [Peter]: This thing is now reasonably complete. [Toerless]: How many people have read the draft? (8 hands up) ************************************************************************* 5. Support of asynchronous enrollment in BRSKI, by Eliot Lear draft-fries-brski-async-enroll Eliot Lear was presenting on behalf of Steffen Fries. [Peter]: We were also looking at this problem. [Eliot]: Probably. I don't think that should be a problem, you may need to apply a little bit of guidance from this draft into that draft. [Michael]: What is lacking should be added to help motivate nderstanding. [Eliot]: Steffen may answer in email list. Probably, 2 things are lacking. One is that there's no serialization for the request available. [Michael]: If something is offline I've sent you something and you sent me back here's your drink voucher. Come back go to the guy at the end of the line and get your certificate. That's what's lacking. [Eliot]: What's lacking but very specifically is how do I match up the request for the response because they're not in order. The second thing that is apparently lacking is some amount of identify information in the request. [Michael]: BRISKI should be change to specify full CMC this is an announced key. It's Est problem but the point is that est defines these two things. (Toerless suggested to make this thing be an update to BRISKI.) [Michael]: I'm just trying to think about how much changes are required to each component by this. (Toerless Eckert and Eliot Lear discussed many details of different techniques, CSR/full CMC etc.) [Ignas]: There are a big list of discusses that need to be addressed. [Eliot]: Once the BRISKI is approved if we could start the adoption process for this. [Toerless]: Who's not author and has read this document? (4 people) ************************************************************************* 6. ACME Integrations with BRSKI, by Owen Friel draft-friel-acme-integrations [Toerless]: Was it also possible to use EST from RA to CA? [Owen]: The EST spec explicitly says it's out of scope. [Doug Montgomery]: I was shocked into reality here of a domain parent without any indication notification of sub domains can always be issued certificates for any subdomain? [Owen]: ACME allows this. (Michael Richardson presented interest to this and will be on side meeting.) [Toerless]: As a working group chair the question in terms of what do you think which working group might be best suited to take on this work and why? [Owen]: The draft is currently structured needs to split apart because the ACME issue in the subdomain certs is a very distinct thing. The ACME working group is happy and wants to do. And how to integrate between ACME and BRISKI/EST that seems like here. [Toerless]: You're thinking the ACME protocol stuff and what happens to the CA might be something for ACME but they're not bothering about the finer details of mapping ACME in an RA into whatever other protocols the RA speaks and that might be better here? ************************************************************************* 7. Summary & ANIMA future activities, by co-chairs Meeting adjourned, see you in Singapore.