In message <[EMAIL PROTECTED]>, "James Kempf" writes:
>>> I think it might be wise to discuss whether the document
>> > should continue to
> >> recommend IPsec with the Security ADs and get some input
> >> from the community
> >> and the security directorate.
> >> draft-arkko-manual-icmpv6-sas-01.txt outlines
> >> some scalability problems with IPsec, even if manual keying
> >> is used, as you
> >> mention below. There is a potential deployment issue as to
> >> what constitutes
> >> a "small" network and at what point the network hits the
> >> scalability barrier
> >> when the network provider will have to completely
> >> reconfigure their network
> >> and turn SEND on. I'm not sure whether it makes sense to
> >> recommend manual
> >> keying for small networks when SEND would work as well and
> >> wouldn't require
> >> a flag day reconfigure if the network grew too large. Also,
> >> manual keying
> >> doesn't make sense for zeroconf networks, because it isn't
> >> zeroconf. The ND
> >> part of SEND could be used for disconnected zeroconf
> >> networks, and the
> >> router part could too if the host came preconfigured with a
> >> collection of
> >> cert trust anchors.
>>
>>
>> => I just want to clarify one thing: it is not my intention
>> to recommend IPsec in any way. I just wanted to mention
>> when it can be used and its limitation. I can add something
>> to say that SEND is the preferred option in general. If the WG
>> wants to remove any reference to IPsec I'm happy to do that
>> too.
>>
>
>Sure, I understand.
>
>My preference would be to say that use of IPsec is deprecated, since, as
>outlined above, there may be significant deployment consequences if it is
>used, and having one way to do something is generally simpler than having
>many.
>
>What do other WG members think?
>
>Also, what do the Security ADs (cc'ed) think?
>
One of the major conclusions of SEND was that IPsec for neighbor
discovery didn't work very well. Given that, and given that we have a
replacement coming, I have no objection.
However... 2461 is at Draft. I'll have to figure out the procedural
consequences of such a change at this point. Of course, I also have
to figure out the consequences of not making the change....
--Steve Bellovin, http://www.research.att.com/~smb
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
