[ntp:hackers] Autokey identity keys

Danny Mayer mayer at ntp.isc.org
Mon Nov 5 03:24:48 UTC 2007


Hal Murray wrote:
>> Problem is, at least with my FIOS connection, the inside address is
>> a 192.168 thing. I would assume the router box translates that to a
>>  routable address to reveal outside. A workasude might be an
>> extended cookie included with every packet.
> 
> I'm pretty sure this is roughly what my NAT box does:
> 
> For a packet going out: Check for an existing connection. If none,
> assign a new port number and create a connection. (That port number
> goes with the external IP address of the NAT box.) Patch the source
> IP address and port from the connection. Forward the modified packet.
> 
> 
> For a packet coming in: Check for an existing connection. If none,
> drop or send ICMP no-such-port Patch the destination IP address and
> port from the connection. Forward the modified packet.
> 
> Thus the local IP Address and port are the only changes between the
> external and internal versions of the packet.
> 

Yes.

> I was assuming that the "cookie" was a cryptographic hash using: 
> session key source IP Address dest IP addresses NTP payload (packet
> type, 4 time stamps, ...)
> 
> If so, then just using the external IP address of the NAT box rather
> than the IP address of the ntpd system when doing the calculations
> would construct a packet that will pass inspection when it gets to
> the other end or verify as good when a valid packet arrives.
> 

No. The client receiving the packet will use it's local receiving
address for verification while the server will use the NAT address. You
will get a mismatch.

> I am assuming that the port numbers are not used for security.
> 

No, they are not used.

> 
> The above NAT description only covers the typical client case where
> the local machine sends the first packet.
> 
> The server case where first packet comes from the outside, requires a
> configuration table that assigns a local IP Address to be the server
> for anything that arrives on a specified port number.  I haven't
> thought much about the fine print, but it seems to do the right thing
> in all the cases I've tried.  (It may be a simple as check the server
> table and setup a connection on the drop or ICMP path above.)

You should read the draft. Of particular interest to you is the
following from Section 4:

>    There are some scenarios where the use of endpoint IP addresses may
>    be difficult or impossible.  These include configurations where
>    network address translation (NAT) devices are in use or when
>    addresses are changed during an association lifetime due to mobility
>    constraints.  For Autokey, the only restriction is that the address
>    fields visible in the transmitted packet must be the same as those
>    used to construct the autokey sequence and key list and that these
>    fields be the same as those visible in the received packet.

While this might imply that you can construct such a packet I don't
think that in practice that it's possible and I'm pretty certain that
the current implementation in the reference implementation requires the
source address and the receiving address to construct a valid autokey.

Danny


More information about the hackers mailing list