[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ndproxy and SEND



If people think ND-Proxy is of enough commercial/deployment interest, and
people feel that security is a major issue, then either the IPv6 WG could
take up the task of extending SEND for proxy ND or SEND could recharter/have
a BOF for that purpose.

The key here is "commercial/deployment interest". IMHO,
starting/rechartering a WG or adding an item to the IPv6 WG charter just
because its a technically interesting problem isn't sufficiently compelling
for devoting IETF resources to the task.

My 0.02 won.

            jak


----- Original Message ----- 
From: "Fred Templin" <osprey67@yahoo.com>
To: "James Kempf" <kempf@docomolabs-usa.com>; "Erik Nordmark"
<Erik.Nordmark@sun.com>; <dthaler@microsoft.com>
Cc: <ipv6@ietf.org>
Sent: Tuesday, March 02, 2004 5:44 PM
Subject: Re: ndproxy and SEND


> If what you are both saying is correct, then perhaps either SEND
> or ND-Proxy (or both) is only half-baked. Which one is it?
>
> Fred L. Templin
> osprey67@yahoo.com
>
> James Kempf <kempf@docomolabs-usa.com> wrote:
> Hi Erik,
>
> > The fact that SEND doesn't currently provide security for proxy neighbor
> > advertisements is an indication that 1) there isn't much perceived need
> > for it and/or 2) it is hard to do since authorization is a challenge.
> >
>
> Indeed, proxy ND was perceived to be one of two hard problems during the
> SEND design discussions, the other being cert-based ND, which would
require
> provisioning of every host with a cert. After discussion, the SEND WG
> decided not to move forward with a solution primarily for tactical
reasons.
> In short, the WG felt that it would be better to wait for clear indication
> of market acceptance for SEND rather than continuing and doing yet another
> RFC that nobody really cared enough about to implement, put in their
> products, and deploy. The original idea was to wait for some time to see
> whether market acceptance was forthcoming, then do a BOF and restart the
WG
> to work on the remaining problems. It's an interesting technical problem,
> though. From one perspective, one could view it as an instance of trust
> transitivity, which is something that in general is not considered to be
> very secure, hence the authorization challenge.
>
> jak
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------