Minutes IETF105: anima

Meeting Minutes Autonomic Networking Integrated Model and Approach (anima) WG
Title Minutes IETF105: anima
State Active
Other versions plain text
Last updated 2019-08-08

Meeting Minutes

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

- Detailed discussion on "Cert Renewal" issue:
Michael didn't understand the attack model during EST server certificate
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.


5. Autonomic setup of fog monitoring agents, by Carlos J. Bernardos

[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

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
[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
[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 
[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 
[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

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 
[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 
[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 
[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

[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.