[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I do not see any reason why the specs should prohibit an intermediate
router from being party to a Security Association between two other
systems (call them S and D) as long as those systems (S and D) choose
to let that router be party to their Security Association. Now key
management (etc) are much harder in such usage, but that is a problem
tobe solved by the users desiring such an arrangement. I don't
think that any standards-track key mgmt protocol is required to
solve that intermediate-router keying problem.
The specs CURRENTLY DO NOT PROHIBIT such an arrangement and it might
be desirable in some user communities to operate in that manner.
Further, I note that the IAB Workshop report from last spring clearly
stated that letting some intermediate routers be party to a Security
Association might be desirable in some cases. (That RFC used different
language but clearly had that meaning).
Finally, in many cases routers will also act as dedicated IP
encryptors on behalf of systems behind the router. In this case,
the end systems might not actually implement end-to-end encryption
themselves and might instead rely on the encrypting routers. This
scenario is especially likely in commercial IPv4 environments where
traffic leaving the firm would be encrypted and traffic within the
firm would not be encrypted. Management of encryption at routers
is often sensible since router administrators are often more
technically sophisticated that plant-floor workstation operators.
- Re: Routing
- From: email@example.com (Carl F. Muckenhirn)