Valery Smyslov writes: > Hi Tero, > > > I.e., when you configure node A for PPK use, you need to give node A > > all the PPKs for all peers it has. I.e., the configuration loaded on > > the node A needs to provide all PPKs it will need. > > If node A is mostly an initiator (e.g. a remote access client), > then it knows beforehand to whom it is trying to connect. So you > may provide it only with PPKs for some nodes. Then the node A > will send PPK_SUPPORTED only in case it is connecting to a peer, > for which the node A has a PPK. This way you may deploy PPK > incrementally or partially (only to some part of the network).
Yes, if your setup is remote access client setup. IPsec in general is host to host, thus there is no servers and clients, and connections can be created in both direction. Actually with remote access client setup, it is enough to install PPKs to the SGW first, and then start installing PPKs to the clients as needed. Each client will typically only connect to one SGW, so they will need just one PPK installed. > For responder the situation is worse. At the moment it sends PPK_SUPPORTED > it doesn't know whether it has a PPK for this particular initiator. > So it must be preconfigured with PPKs for all possible initiators > before starting to reply with PPK_SUPPORTED. Yep, or it can also use the source ip address of the incoming packet to help here. I.e., if you have site to site mesh setup for your VPN service, then each site will have static IP-addresses, and responder can see from the IP-address whether it has PPK for the other end or not. This of course does not work with the remote access clients, or even in cases where the sites do not have fixed IP-addresses (i.e., small or home office SGWs). Anyways we do not need to specify all of these cases in the specifications, those are mostly implementation details, which each implementor can specify depending on the environment their product will be working in. We just need to understand what are the limitiations with the selected method, and in this case it is that responder needs to know from the IP-address alone whether it has the PPK it can use for the incoming connection, and from that decide whether it should or should not send PPK_SUPPORTED notify. > > Actually for both ppk_id, and the PPK value used in the calculations, > > I would suggest following: > > > > Both the the ppk_id inside the N(PPK_IDENTITY) and the PPK > > value used in the SK_d/SK_pi/SK_pr calculations are opaque > > octect streams. Implementations supporting PPK, MUST support > > ppk_ids having length of less than 64 octets, and MAY support > > longer ppk_id values. The PPK itself MUST have length between > > 16 and 64 octets. > > I'd rather add a type field to ppk_id. So the ppk_id is constructed > of 2 fields: type and value. Types could be: > 1. raw id > 2. OTF file offset > 3. PPK dependent id > ... > > For the 3rd option the ppk_id is constructed using the PPK > itself and a session parameters, e.g. ppk_id = prf(PPK, Ni | Nr). > This would allow the responder to check whether PPK is correct > before verifying AUTH payload. > > In general, having a type value would simplify PPK management in case > a host have PPKs of different types and need to look them up > in different storages. That is one possibility. Should the type be 8-bit or 16-bit? I assume the registry itself should be IANA registry with designated expert review or something like that. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
