HIPv2: cryptoagility for DNS proxy

[Miika Komu]

HIPv2 requires some agility also in the DNS proxy. Let's have a look at an example.

Remote host advertises its HIs with the following algorithms in DNS:
* x
* y
* z

But the local host supports only the following algos for its HITs:
* y

The result: the DNS proxy of the local host looks up the remove HIs, it should return only the remote HIs with algo Y to maximize compatibility. In other words, the proxy filters out incompatible remote addresses.

When the proxy does not find any compatible addresses, the results depends on local policy (i.e. command line argument to the proxy): either nothing gets returned or the proxy returns regular IP addresses.

Feel free to comment, this is just my initial suggestion how to resolve this. I think we could have this feature already in HIPv1 even though it is not strictly speaking needed (but we do have multiple algos).

[Paul Tötterman (ptman)]

So I should just filter the DNS answers based on the PK algorithm field in the HIP RR? Any suggestions for how I should know which algorithms the local HIP daemon supports? Generate python code based on ./configure or ask the daemon through hipconf at hipdnsproxy startup?

[Miika Komu (miika-iki)]

The algorithms can be used/discovered as follows:

hipconf daemon add hi default # enables multiple identities for hipd
hipconf daemon get hi all # lists all local identities (you can use this in the DNS proxy)

I think you should add an command line option that filters the identities because it's not needed in HIPv1 (which will co-exist in parallel with HIPv2). Detecting this is tricky because some host associations can use HIPv1 and others HIPv2 (see lp:913516). Or do the DNS records (in draft-ietf-hip-rfc5205-bis) distinguish between the two protocol versions?

Also, what do plan to do if all identities get filtered out? Return an empty response or IP addresses?

[Miika Komu (miika-iki)]

Few clarifications after some discussion with Xin:

1. I realized that the issue is irrelevant of HIP version number because (in theory) it's possible to include new algos in HIPv1.
2. Retrieving identities with "get hi all" is not an idea solution because it's just the run time identity configuration, not the actual algorithm support. For example, the following scenario works:
* Initiator and Responder support both algos A and B
* Initiator has a run-time identity for algo A and Responder for B

As the list of algorithm is quite static, I would suggest to store in in DNS proxy directly instead of querying from daemon. See the list of supported algos e.g. in hipd/hidb.c:get_public_key(). You could add a note in the file lib/core/protodefs.h near HIP_HI_xx definitions to update also DNS proxy whenever new algorithms are introduced.

This way, no new command line parameters for DNS proxy are needed and you can filter based on PK algorithm field. So, this should be quite simple.

(Note: a new hipconf option would introduce an additional bottleneck to the boot-up sequence between hipd and dnsproxy, so I am not encouraging it)

[Paul Tötterman (ptman)]

The DNS records are exactly the same for RFC5205 and RFC5205-bis.

I was planning on returning whatever the DNS proxy returns if there are no HIP records, if there are not HIP records with compatible algos.

Are there some well known HITs that use DSA instead of RSA as the algorithm or should I just generate my own for testing?

This is beginning to look suspiciously easy, but I'll just use more effort to make automated tests and refactor the huge mess that is the main loop currently.

[Paul Tötterman (ptman)]

DNS UDP responses don't seem to fit more than one HIP RR, so I'll have to implement DNS TCP client in order to get all records to filter.

[Miika Komu (miika-iki)]

Let's file this into a separate bug report.

[Miika Komu (miika-iki)]

I re-prioritized this task because this will require some feedback from the HIP WG and Xin is going to send email about this. The dual support in hipd and DNS proxy actually a bit more complicated than I originally thought; either we need a "flag day" for HIPv2 or we need to modify the specifications for smoother transition to HIPv2 (or in the future, HIPv3). The TCP client support can developed independently of this.