> Yes, servers will support AO, if for no other reason than they support
> BGP and MD5 now.
the problem is that they don't really. check out, for example, the
freebsd md5 hack. it is send-only, does not check on receive. i am
told there are similar messes elsewhere.
basically this is a mess.
o ipsec is not fully supported to the control plane, and it is
a masters project to specify compatible parameters. a sad ietf
disaster.
o md5 is not fully supported (on servers), but might be fixed more
easily than AO. it is weak in theory and widely deployed and
deployable in practice.
o ssh is not fully supported _as a library_ in routers, hacking is
possible and is being done.
o AO is nice paperware but does not have significant running code on
servers or routers. it tells us something about the ietf to have it
push so hard on something with so little running code.
which is why we're pretty much using cleartext tcp today. this is ok
for early deployment. and it will definitely encourage ops to put the
cache servers close to the routers, which is good :). but it is not a
good mid-term solution.
we'd really like to see a mandatory-to-implement so that ops have a
clear deployment scenario. but ssh is the only strong candidate for
that at the moment, and it's not pretty. at least one router vendor has
implemented. and we have ssh implementation across a wide variety of
servers.
AO is the likely long term mandatory-to-implement, but could be a long
way out on servers.
sigh.
randy
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
