Subject: Re: Forgery resilience: straw man proposal

From: Alex Bligh <[email-masked]>
Date: Wed, 30 Jul 2008 10:17:43 +0100

--On 30 July 2008 10:14:17 +0100 Alex Bligh <[email-masked]> wrote:

> 1. Use IPsec AH in transport mode between the stub resolver and the
>    recursive nameserver. This provides authentication of the recursive
>    nameserver to the stub resolver (see below), integrity protection,
>    replay protection and (as an unneeded bonus I think) non-repudiation.

I should have added that it does not suffer the computational overhead of
requiring encryption/decryption at each end.

Alex

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Alex Bligh <[email-masked]>
Date: Wed, 30 Jul 2008 10:14:17 +0100

Here's a straw man proposal for forgery resilience between stub resolvers
and recursive nameservers with minimal invention of new protocols:

2. Determine availability of, and the public key for the recursive
   nameserver the same way as its IP is obtained, IE through a BOOTP/DHCP/
   IPCP option in most cases. If it's not there, use normal IP. If it
   is there, do not fall back. Whilst DHCP options etc. can be
   spoofed, they'd have to be spoofed early, and in any case if Malory
   can spoof these options he can simply insert his own nameserver
   IP addresses anyway. The really paranoid can protect BOOTP/DHCP/IPCP
   in other ways.

3. IPsec AH in transport mode is not compatible with NAT. This is partly
   a blessing in disguise. This means that a typical middlebox in the
   form of an end user NAT box needs to act as an ALG, i.e. either
   a caching resolver or what in old DNS terminology would have been
   called a "forwarder". This has two advantages. Firstly, in this
   scenario it's the NAT box which is the recipient of the DHCP/BOOTP/IPCP
   option, so is best placed to make the IPsec queries and need not
   then distribute this information (and indeed should not if it's
   NATing). Secondly, as the NAT box originates the IPsec queries, it
   can then be optional for devices on the end-user side of the NAT to
   speak IPsec at all, as their query will simply be sent to the
   NAT box, which would forward a query for the same records on but
   wrapped up in IPsec. Of course as a forwarder the NAT box could
   advertise its own IPsec key to prevent forgery between the NAT
   box and the end user for IPsec AH aware end users. Note that NAT
   (or more accurately NAPT) seems to break other forgery resilience
   schemes (e.g. entropy increasing ones) so some degree of rewrite
   is necessary here, and this has the advantage of a rewrite only
   on middleboxen than need not extend to end user boxes (as well
   as at the caching resolver / ISP side).

4. As it is unnecessary for the query originator to be authenticated
   to the resolver (as opposed to vice versa), all query originators
   could use the same null key.

Please make allowance for lack of caffeine so far today. I don't claim
this is the best solution, merely that it should be considered amongst
others.

Alex