Re: Regarding offloading IPv6 addrconf and ndisc

[Hugo Santos <hsantos@av.it.pt>]

[-- Attachment #1: Type: text/plain, Size: 2006 bytes --]

> A couple of basic questions:
> 1. Can we just proceed assuming it is non-secure until a later time when
>    the certificate path is established?

   This is not something which is described in the standard. In fact,
 processing the RA without a certificate path to the router already
 assumes the host is configured to so do (assuming unverified messages
 are treated as normal non-secure ones). Treating it as non-secure would
 allow an attacker to temporarily receive packets from the host if it
 has no secure router to be used (in the same or other interfaces).
 This may allow it to retrieve some of the user's info (think web-login
 portal) and it just has to be on-link (typical NDP attack). A solution
 would be not to assume it is non-secure, but instead cache or drop the
 RA and initiate the process to obtain a certificate path. This however
 does not allow the kind of behaviour that Dave described in one of is
 earlier e-mails, where packets are processed in order.

   Also, the host cache needs to hold X.509v3 certificates, and even if
 a lighter crypto-hash based check is available (if CGAs are used as
 well, to make sure the packets come from the packet's source address),
 hosts will end up having to perform RSA signature checks.

> 2. What if user process dies? or gets overwhelmed?
>    One of the assumptions of the any well designed kernel is that the system should never
>    hang because some user application died or waited for ever.

   Of course that this is a real problem. However, if the control daemon
 dies the kernel won't die. Depending on the implementation -- you might
 temporarily get out of addresses, if the addresses are flushed when the
 control daemon dies, etc. But, just like a routing daemon is critical
 to a router, this control application would also be critical to the
 host's connectivity. And if it dies, it needs to be restarted. The
 application might be itself complex, but in the end we moved this
 complexity away from the kernel.

   Hugo

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]