At Mon, 25 Jun 2007 16:16:29 -0400,
"Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote:
> First, it is not clear which "security problem" this bullet tries to
> indicate.
>
> <hs> The problem we refer to is the fact that Host1 and Host2 have the
> same GUA on the same link! This is an obvious problem because Host1 is
> able to get an authoritative (because Host1 issued an unchallenged DAD
> for GUA) GUA that is also later assigned to Host2. Note that Host1 does
> not need an incorrectly implemented or hacked up IPv6 stack to reach
> this problem scenario - the problem arises with a fully compliant IPv6
> host stack on Host1 and Host2 using only the interface exported to an
> end user. If Host2 was NOT allowed to skip DAD, then Host2 will issue a
> NS(DAD) for GUA and Host1 being a compliant host would reply with an NA
> saying "I have this GUA". The net result is that traffic that should
> have gone to Host2, goes to Host1 instead - why is this not a security
> problem?
I, for one, would not call it a "security" problem; it's an accident.
As an "accident", the problem described in your draft is just
another form of a weird situation that 2462bis already explains. And
since the possibility of the accident didn't fully convince the
opponents when we discussed 2462bis, I don't think this new draft can
now do it.
> <hs> Do you acknowledge the problem we describe above?
As an accident, yes. And I'm now more confident that it's not
significant enough to delay the publication of 2462bis.
Without the editor hat on:
> Since we realize
> that 2462bis I-D is in AUTH48 state, a change like this may require
> IETF-wide review and that would further delay 2462bis becoming an RFC.
> But then where do we put changes like ours? Our I-D is at the beginning
> of the process, so it may be an appropriate place for this and any
> further changes if they can't make it into 2462bis.
Before seeking the place to put the changes, the draft first needs to
convince others about the changes. If it goes successfully, the new
document will be published as a separate RFC (I understand it's a time
consuming process, but in my understanding standardization at the IETF
works that way).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
