Tatuya,
OK, it's alright to say an accident, but this accident caused the
security problem because we still think if Host1 is receiving traffic
that was meant to go to Host2, it's a security problem.
You also described the other security problem case where you said, Host1
is not compliant to IPv6 standards and deliberately malicious and we
granted you the fact that Host1 being a rouge can decide to ignore the
NS(DAD) from Host2. But even in this case the rtr will be able to detect
the problem if our proposed solution is applied - the solution being
Host2 will not skip DAD for GUA.
See my response in earlier email in quotes below:
"<hs> The second problem case, when Host1 is a rogue and not compliant
with IPv6 standards, sure Host1 can ignore the DAD-NS from Host2 but the
IPv6 router on the link MAY catch this duplicate since the router has
also seen this NS(DAD). We envision that the router logs an error
message. Again, in our previous case above, if Host2 had skipped NS(DAD)
then the router would not catch this problem."
Here is the summary of what stands as of today.
Problem1: Host1 is not a rogue - it has already been acknowledged in
this mailer that this is a real problem that is not detected.
Solution1: What we propose in our I-D will fix this problem. We have
explained in an earlier email how.
Problem2: Host1 is a rogue - you have acknowledged this is a problem.
Solution2: The same solution from 1 is applied here. Host2 MUST NOT skip
DAD. Even when Host1 is a rogue and will ignore DAD from Host2 for GUA,
the Ipv6 rtr picks up the dup and logs an error message.
Problem1 is a worse problem than problem2 because the attack can be
mounted by an IPv6 novice, and is not detected.
Let's focus on the problems at hand and solutions - forget delay of
2462bis I-D or what have you. Why are we referring to text in 2462bis as
an admittance that accident cases can exist when we have a solution for
such cases?
Thanks,
Hemant & Wes
-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED]
Sent: Monday, June 25, 2007 10:08 PM
To: Hemant Singh (shemant)
Cc: Brian E Carpenter; Fred Baker (fred); [email protected]
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent
changes suggested to 2462bis-08
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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
