[00:45:20] behcet.sarikaya joins the room [00:46:24] Hello [00:48:41] Roque@lacnic.net joins the room [00:48:48] marcelo: light agenda. three presentations report milestones: hash threat analysis, lets wait for the public key report. proxy - in WCLC. three other issues: public key, certificate and DHCP (that needs more work). [00:49:15] Signature Algorithm agility [00:49:22] presentation now [00:50:22] Work done, try to cathegorize routers and hosts by their ability to support crypto algorithms [00:50:46] router can: have certs (to act as routers and have a CGA). [00:51:06] ruouter can have a signature and veritication capability [00:51:14] hosts normally handle CGAs [00:52:16] (marcelo) there are multiple situations [00:52:57] CGA that have both an RSA an other keys or a CGA that has just other kind of keys [00:53:34] we have a wide variety of type of algorithms supported in hosts [00:53:51] what do the WG opinion? should we support all the algorithms? [00:54:11] (person1 name no clear) we should consider a basic set [00:54:15] RSA CGA [00:54:34] (marcelo) the point of being here is that some devices wants shorter keys [00:54:40] person1 is Jean Michel Combes [00:55:07] (Jean Michel Combes JMC) you need to consider back-compatibility [00:55:12] (thanks tony) [00:55:46] (Stephen Kent) The docs are not implemented, you have flexibility [00:56:00] This is not IPSEC. [00:56:43] There is an asymmetric, hosts (mobile devices) will be more likely to use less CPU, but RSA is asymmetric [00:57:25] (marcelo) what about Neigh. Solicitation? In this case a host will need to sign the messages. [00:57:33] (SK) yes, that is correct [00:58:19] (marcelo) You other statement is that in this scenario we do not need to worry abour back-compatibiliy as has not be implemented [00:58:54] (SK) yes. "time passed we are thinking thing differently, we want to change" [00:59:10] you need to be able to do this. Original doc. where RSA specifics. [00:59:47] (presentation continues) [01:00:17] We need 2 things to get agility: CGA update & SEND update [01:00:57] CGA Update: New CGA parameter data structure extention. Old: CGA generating multiple keys [01:01:14] went through packet description [01:01:38] for support of multiple keys [01:02:08] open to discussion if the extension should be located here [01:03:02] (marcelo) two things to discuss. Public key agility will work in CGA today, the only problem is that is says that SHOULD be RSA. What this extensions allow is to have MULTIPLE Public keys. [01:03:26] Two questions: how to support multiple algorithms and how to support multiple public keys. [01:04:18] (francis dupont) you only need to extend the second parameter [01:04:45] "new things inside the CGA" [01:05:14] (marcelo) why do you believe that there attacks? [01:05:16] not "second", SEC parameter [01:05:55] (francis) if you have two public keys and you break the weakest one, you break the all thing. [01:06:04] (thanks tony...again) [01:06:29] (francis) I do not see the case that more than one key is usefull [01:07:16] (marcelo) a router with multiple PK algorithm support to communicate with different hosts. we can use the same CGA using different algorithms [01:07:21] you do not need another address. [01:07:27] (francis) disagree. [01:07:56] you should not have different level of security. [01:08:15] (marcelo) it is not about level of security but different algorithms [01:09:19] (SK) The motivation to change to a different algorithms is because it normally saves battery power in mobile devices. [01:10:08] (francis) good to be able to switch algorithms but not to use different algorithms at the same time. [01:10:25] (marcelo) the problem is that if you change the key, you change the address. [01:11:27] once you change the address, you need to do new ND [01:12:17] (francis) imagine SEND and CGA in public internet. Deployment will come when security is important. [01:13:50] (Sean)first concern, how can I say that one algorithm is weaker than other?. [01:14:55] (marcelo) the problem that francis is describing is that you have multiple instance of SEND, where is one instance do not work you can try the other one and try to attack the weaker part [01:15:39] (francis) maybe describing, first try this king of algorithm with this kind of hash... [01:15:47] second, etc. [01:15:56] (presenter) too many combinations [01:17:36] (gabriel) There may be a host that implement "instance A" and another next to that one that implement "A and B" and you see it as two hosts. Also, there should be recommendations about how to select from A to B. [01:18:11] (francis) It must be a different address, to show that it is a different "thing" [01:18:37] (marcelo [01:18:39] ) [01:19:07] (francis) if it is a property of the CGA you do not need to negotiate. [01:19:39] (marcelo) suppose that your application cannot do SEND with the algorithm....you need to come back to ND plain [01:20:01] (JARI) we are not moving information from ND to other layers [01:20:04] that would be bad. [01:20:42] (michaela - presenter) there is no way to bind one address to more than one key [01:21:16] (discusion between michaela and gabriel) [01:22:33] (gabriel) there is no limit on the numbe of keys? [01:22:46] (michaela) we can change that to the next version. [01:23:04] should we limit the length of the packet or the number of keys? [01:23:14] (presentation continues) [01:23:29] CGA Update as per RFC3972 [01:24:04] Classification of Nodes for Algorithm Negotiation (H1 and H2 hosts) [01:24:44] (H3 and H4) [01:26:14] Routers classification: R1 and R2 [01:26:22] R3 and R4 for next version [01:26:33] SEND Update: [01:27:08] optional router assisted BD mechanism [01:27:26] New/Modified ND options: [01:28:01] Supported Signature Algorithm Oprions: indicates which signature algorithm is available. [01:28:34] update RSA Signature Option to a new Option: Universal Signature Option [01:28:51] Supported Signature Algorithm Options (SSA) [01:30:09] (marcelo) what is the signature type? [01:30:24] (michaela) we will assign bits 3-7 [01:30:30] to RSA, etc.... [01:31:15] (Stephen kent) Signature Algorithm Type and the specific algorithm may not be the same as in ECC you need to know the curve [01:31:37] that it is used. Small number widely used today, that may change in time. [01:31:52] (michaela) we have 5 bits, we believe they are enough [01:32:20] (presentation continues) [01:32:56] Universal Signature Option: uses the Reserved filed in the RSA Signature Option to support multiple signatures. [01:33:25] () is this the same type or a different? if it is the same type what about the back-compatibility? [01:33:50] (michaela) it will thing that it is RSA and if it is not, it will fail [01:34:17] we are open to suggestions [01:34:47] (person 2 -- not clear the name) we need to specify that we fall back to RSA [01:36:40] (presentation goes on) [01:36:46] negotiation process [01:36:55] wmhaddad joins the room [01:37:17] two cases shown [01:38:37] homogenus and heteregeneous netowork [01:38:59] (dave thayler) two question. Any reason this two phases not be done in paralel [01:39:01] ? [01:39:07] (michaela) no reason [01:39:49] (dave thayler) if B do not want to respond to A there is not need to enter phase 2. [01:40:08] (michaela) correct. Just ilustration examples not requirement [01:40:37] (presentation goes on) [01:41:23] (dave) if this fails you go back to plain ND? answer yes [01:42:03] (dave) the r flag is not necessarily? [01:42:20] (michaela) not necessary we are willing to take it out [01:42:59] behcet.sarikaya leaves the room [01:43:24] (presentation continues) [01:43:38] Adding a router the "notary function" [01:46:18] (question in the floor) is this a sign message inside another signed message? What about the MTU? [01:46:38] (michaela) we think that it needs to be shorter that the MTU :-) [01:47:00] (floor) it may be difficult in some cases, please do the maths. [01:47:39] (jary) same order of size [01:47:54] I believe it can work from an MTU perspective [01:48:25] (dave thaler) any threat analysis done? [01:48:42] (jary) do not mather [01:49:05] you can send other packets. [01:49:18] (dave thaler) need security consideration section [01:49:47] (question floor) I would not use the router as notary [01:50:02] Jean Michel Combes JMC [01:50:14] (Jean Michel Combes JMC) [01:50:26] what about NAD? [01:50:46] Address Duplication detection? [01:51:04] (michaela) you need a valid address. [01:51:06] Could use unspecified address I think ? [01:51:15] it may not work [01:51:22] (it only needs to have a valid router signature) [01:51:29] tony you want me to ask the question on the floor? [01:51:38] You can relay please [01:52:22] Dave Thaler joins the room [01:52:25] I think so [01:52:42] answer: what about the reply [01:52:55] You could multicast it back (as proposed) [01:53:08] (no need to relay that) [01:53:26] (thanks for relaying) [01:54:11] (marcelo) the draft a great work, have analyze a super set of support [01:54:31] do we want to reduce the scope of things we want to support? [01:55:40] question to the floor...or the jabber room [01:55:49] (francis) simple proposition [01:56:03] please rename security parameter and number [01:56:13] (dave thaler) simpler is better [01:56:45] unless there is a real need for things like the "r" flag lets eliminate it and try to identify what else to simplify [01:56:56] (marcelo) what about the kind of nodes? [01:57:17] issue moved to the list and next meeting [01:57:30] next topic - certificate profile [01:57:45] (ups- additional comment form Gabriel) [01:58:43] addresses come and go, and have more addresses can simplify things [01:59:21] giving that we do not have much deployment can we call the previous SEND docs as an "experiment" [01:59:39] ? [01:59:54] no more answers [02:00:03] (next presentation Certificate Profiles) [02:00:33] SEND uses X509 certs but not particular info on the Certs. [02:00:51] desition to use SIDR profile [02:01:00] and not continue with the work [02:01:23] there was a minor issue that SIDR Certs did not allowed EKU [02:01:41] that was changed and the work is much lower now [02:01:56] EKU still needs to be specified. [02:01:59] behcet joins the room [02:02:06] in CSI [02:02:42] Three EKU: Router/Proxy/Client [02:03:29] (dave thaler) wonder if there is a fourth, as a notary [02:03:52] incremental deployment [02:04:36] Open issues: [02:04:58] How to authorize a particular router to be the default router? [02:05:06] backward compatibility [02:05:12] CRL transport for SEND [02:06:27] (marcelo) the certificate must contain the prefixes that you use for address autoconf. not the ones you are allow to route. [02:06:52] (jari) the problem is the wording. [02:07:11] authorize to advertise is clear, what about authorize to route? [02:09:25] (stephen kent) RPKI is authorizing them to originate routes from a particular ASN, not looking for local problems to get to a destination. [02:11:45] (dave thaler) the authorization to route any route even the default should be explicit [02:11:58] and can be say that way in the doc. [02:12:46] (marcelo) SEND does not currently make this distinction and the explicit mechanism is what is in place today. [02:12:54] (jary) agree with marcelo. [02:13:37] (greg daley) problem with CRL, the only path to verify the CRL is through the router. Most CRL are large. [02:13:50] we may want customer to do verification techniques [02:13:53] but not in SEND [02:14:43] (marcelo) does anybody think we need to make a distinction that a router is a default router? [02:15:38] (gabriel) I rather say default router, but nothing more about other routes. Other documents dealing with this issue. [02:15:49] (presenter) does not go far enough [02:16:22] thing about 2191 [02:16:42] (gabriel) unless otherwise specified you can assume that is a default router. [02:17:57] (deve thaler) it is not only the default router but also any other route, there is no reason for a distinshment. The collection of specific = default [02:18:12] wmhaddad leaves the room [02:18:49] (gabriel) what about the side of the CRL? [02:19:34] (side ? you sure it's not "size" ?) [02:19:43] (sorry size) [02:20:02] a well design sistem should not have large CRLs as certificate should expire [02:20:21] (greg) if we can get a trusted part we can offload the work [02:21:00] (stephen kent) you need to get the network to route you to get the CRL [02:21:11] CRL tells you when the next one will be issued [02:21:30] when you deny the possibility to get the CRL you get in a bizarre situation [02:22:26] (presenter) this break backward compatibility....is this an issue? (same question as before). [02:23:07] (marcelo) propossal to support only CRL and not present SEND prefix validation. [02:23:32] consensus. [02:23:46] (marcelo) is the document ready for adoption? [02:24:15] 8 in favor no opossition. [02:25:12] (Jean Michael) How to provisioning of certificates? there was something about DHCP... [02:25:38] (marcelo) now, only the profile, if someone wants to talk about and write about DHCP great [02:28:04] (roque) what we are working at this moment is not in that stage, maybe when facing secure BGP and needs to issue certiicates to routers [02:28:21] it may make sense to use same mechanism. [02:28:27] (next presentation) [02:28:44] SEND SGA and DHCPv6 - student work [02:33:58] behcet leaves the room [02:34:37] implementation based in linux [02:34:43] 2.6.24 kernel [02:35:01] Router based in Quagga and dibbler as DHCP server [02:35:11] (can you relay) Question for Sean, what's the licence of the new part of the software that we be written ? Are some of the presented thing already available ? [02:36:05] GPL licence [02:36:08] Ok, sounds good (thanks for relaying) [02:36:14] will be a web page to download the sources [02:36:47] ok done [02:36:52] session adjurned [02:36:57] Roque@lacnic.net: thanks [02:37:13] you are welcomed [02:37:15] Roque@lacnic.net leaves the room [02:37:23] tony.cheneau leaves the room [02:59:27] Dave Thaler leaves the room [16:06:18] wmhaddad joins the room [17:44:25] wmhaddad leaves the room [22:52:24] wmhaddad joins the room [23:56:07] wmhaddad leaves the room