Minutes IETF105: anima
minutes-105-anima-03

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.