Subject: [v6ops] Review of draft-ietf-v6ops-dhcpv6-slaac-problem

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Feb 2016 21:05:40 -0300

Folks,

I support publication of this document as an RFC. Here's my review:

** Technical **

* Section 1, page 3:
>    The M and O flags are advisory, not prescriptive.  For example, the M
>    flag indicates that addresses are available from DHCPv6, but It does
>    not indicate that hosts are required to acquire addresses from
>    DHCPv6.  Similar statements can be made about the O flag.  (A flag is
>    also advisory by definition in standard, but it is quite prescriptive
>    in implementations according to the test results in the appendix.)

mm.. could you quote something from RFC4862 regarding these bits "being
advisory"?

* Section 2.1, page 4 (and other instances):
> 
>    o  A (Autonomous) Flag
> 
>          A flag is defined in the PIO, "When set indicates that this
>          prefix can be used for stateless address configuration as
>          specified in [RFC4862].".

This, as is, is misleading: I'd separate the analysis of "M" and "O" --
which are mandatory in the RA header, vs the A flag, which is only
present in the PIOs, and hence is optional.

* Section 3, page 4:
> More specifically, it is
>       unclear whether RA (with M=1) is required to trigger DHCPv6; in
>       other words, It is unclear whether hosts should initiate DHCPv6 by
>       themselves if there are no RAs at all.

This is confusing. There are two different cases here: M=1 -- for which
I don't think there's any ambuiguity, and no RA, in which case there is.

* Section 6, page 10:
>    An attacker, without having to install a rogue router, can install a
>    rogue DHCPv6 server and provide IPv6 addresses to Windows 8.1
>    systems.  This can allow her to interact with these systems in a
>    different scope, which, for instance, is not monitored by an IDPS
>    system.

Not sure what you mean. Do you mean that with other OS, an attacked
would be required to forge RA's in order to be able to perform this
attack? - If so, please say so. :-)  Additionally, these RFCs would be
helpful here: RFC7610, RFC7123, RFC6105.

* Section 6, page 10:
>    The behaviour of Fedora 21, Centos 7 and Windows 7 can be exploited
>    for DoS purposes.  A rogue IPv6 router not only provides its own
>    information to the clients, but it also removes the previous obtained
>    (legitimate) information. 

Note sure what you mean by "rogue IPv6 router". Are you referring to
spoofed RA?

* Appendix A, page 12:
> 
>    The authors from two orgnizations tested different scenarios
>    independent of each other.

It's not clear from this text whether you tested the same thing, or
different things (i.e., no overlap, partial overlap, or full overlap of
the tests).

While it is valuable to indicate that multiple tests were performed
independently (i.e., they were validated), what's useful from the pov of
the reader is to get the aggregate of the tests, possibly in a table.

If all the overlapping text shielded the same result, please say so, and
just publish the aggregate of the results. If the same test shielded a
different result in each of the test scenarios, please note which ones,
and try to explain why the same test shielded a different result.

** Editorial **

* Section 1, page 3:
>  to to discover 

Writeo -- remove one instance of "to"

* Section 1, page 3:
>    o  an M (Managed) flag, indicating that addresses are available from
>       DHCPv6 or not
> 
>    o  an O (OtherConfig) flag, indicating that other configuration
>       information (e.g., DNS-related information) is available from
>       DHCPv6 or not
> 
>    o  zero or more Prefix Information (PI) Options
> 
>          an A (Autonomous) flag is included, indicating that the prefix
>          can be used for SLAAC or not

Bullet #3 should follow the style of the fit two bullets.

* Section 1, page 3:
> This
>    document analyzes possible divergent host behaviors might happen
>    (most of the possible divergent behaviors are already observed in
>    popular operating systems) and the operational problems might caused
>    by divergent behaviors.

missing "how" in "[how] possible different..."

* Section 3, page 4:
>       In standards, behavior of DHCPv6 and Neighbor Discovery protocols
>       is specified respectively.

s/respectively/separately/? -- if not, what do you mean?

* Section 5.2, page 9:
>          release the current SLAAC address and acquire another new SLAAC
>          address (might comes from different source).

s/comes/come/

* Section 6, page 10:
> 
>    If an attacker wants to perform MiTM (Man in The Middle) using a
>    rogue DNS while legitimates RAs with the O flag set are sent to
>    enforce the use of a DHCPv6 server,

s/legitimates/legitimate/

* Section A.2.3, page 19:
> these scenarios there are two routers on the same link. 

s/these/These.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 23 Feb 2016 03:41:31 +0000

Hi Fernando,

Thanks much for your support and comments. Please see replies inline.

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Fernando Gont
> Sent: Tuesday, February 23, 2016 8:06 AM
> To: [email-masked]
> Cc: IPv6 Operations
> Subject: [v6ops] Review of draft-ietf-v6ops-dhcpv6-slaac-problem
> 
> Folks,
> 
[Bing] In the previous version SLAAC (RFC2462), there was some nice prescriptive processing of the flags, but it was just removed in RFC4862 as stated "Removed the text regarding the M and O flags, considering the maturity of implementations and operational experiences...". I believe that is the main reason of why current OSes' behavior diverts.

> This, as is, is misleading: I'd separate the analysis of "M" and "O" -- which are
> mandatory in the RA header, vs the A flag, which is only present in the PIOs,
> and hence is optional.
[Bing] I agree with you that separating them is more logically clear. But the trouble thing is, according to Divergence 2-1 (in Section 4.2), A flag and O flag have some relationship in some OSes. So I just felt it had to be discussed together. Do you have any suggestion? I'd be glad to hear. Thanks. 

> This is confusing. There are two different cases here: M=1 -- for which I
> don't think there's any ambuiguity, and no RA, in which case there is.
[Bing] I think we're talking about the same thing. However, the text intends to emphasize in another perspective: if "no RAs" is ambiguity, it means some OSes just wait to the M=1; if they don't see it, they just don't do DHCPv6. This implies a dependency relationship which in my mind is not proper.

> would be required to forge RA's in order to be able to perform this attack? -
> If so, please say so. :-)  Additionally, these RFCs would be helpful here:
> RFC7610, RFC7123, RFC6105.
[Bing] Yes, exactly what you mean. Because Win8.1 just ignore RAs to independently interact with DHCPv6 server, it lacks a protection such as RA guard on this kind of attack.
I'll see whether it's good to reference the RFCs here, especially the RFC7610. Thanks for the info.

> Note sure what you mean by "rogue IPv6 router". Are you referring to
[Bing] Yes, this specifically means the flag transitioning. E.g., when M is turned off, these OSes would immediately release the DHCPv6 addresses. This could be used by the attacker.
I'll make this clearer in the next version.

> It's not clear from this text whether you tested the same thing, or different
> things (i.e., no overlap, partial overlap, or full overlap of the tests).
> 
> independently (i.e., they were validated), what's useful from the pov of the
> reader is to get the aggregate of the tests, possibly in a table.
> 
> If all the overlapping text shielded the same result, please say so, and just
> publish the aggregate of the results. If the same test shielded a different
> result in each of the test scenarios, please note which ones, and try to
> explain why the same test shielded a different result.
[Bing] Good point, thanks. The two tests were partial overlapped, and the overlapped part was consistent in results. We just aggregated the results as Section 4, and keep the raw details of the two tests in the Appendix. 
When people read the document, we assume it is sufficient to get aware of the problems from the main body text; and if somebody interested in the test details, then he/she could get it in the Appendix.
Do you think it's ok?

The below editorial comments will be addressed as well.
I really appreciate your careful review.

Best regards,
Bing

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2016 08:06:40 -0300

Hi, Leo,

Comments only on those parts that needed additional "discussion"...

On 02/23/2016 12:41 AM, Liubing (Leo) wrote:
>> ** Technical **
>> 
>> * Section 1, page 3:
>>> The M and O flags are advisory, not prescriptive.  For example,
>>> the M flag indicates that addresses are available from DHCPv6,
>>> but It does not indicate that hosts are required to acquire
>>> addresses from DHCPv6.  Similar statements can be made about the
>>> O flag.  (A flag
>> is
>>> also advisory by definition in standard, but it is quite
>>> prescriptive in implementations according to the test results in
>>> the appendix.)
>> 
>> mm.. could you quote something from RFC4862 regarding these bits
>> "being advisory"?
> [Bing] In the previous version SLAAC (RFC2462), there was some nice
> prescriptive processing of the flags, but it was just removed in
> RFC4862 as stated "Removed the text regarding the M and O flags,
> considering the maturity of implementations and operational
> experiences...". I believe that is the main reason of why current
> OSes' behavior diverts.

It would be great if you could elaborate a bit on this.

>> This, as is, is misleading: I'd separate the analysis of "M" and
>> "O" -- which are mandatory in the RA header, vs the A flag, which
>> is only present in the PIOs, and hence is optional.
> [Bing] I agree with you that separating them is more logically clear.
> But the trouble thing is, according to Divergence 2-1 (in Section
> 4.2), A flag and O flag have some relationship in some OSes. So I
> just felt it had to be discussed together. Do you have any
> suggestion? I'd be glad to hear. Thanks.

>> * Section 3, page 4:
>>> More specifically, it is unclear whether RA (with M=1) is
>>> required to trigger DHCPv6; in other words, It is unclear whether
>>> hosts should initiate DHCPv6 by themselves if there are no RAs at
>>> all.
>> 
>> This is confusing. There are two different cases here: M=1 -- for
>> which I don't think there's any ambuiguity, and no RA, in which
>> case there is.
> [Bing] I think we're talking about the same thing. However, the text
> intends to emphasize in another perspective: if "no RAs" is
> ambiguity, it means some OSes just wait to the M=1; if they don't see
> it, they just don't do DHCPv6. This implies a dependency relationship
> which in my mind is not proper.

Ok, now I see what you mean. However, looking at RFC4862, this is a
lowecase "may".

>> different things (i.e., no overlap, partial overlap, or full
>> overlap of the tests).
>> 
>> While it is valuable to indicate that multiple tests were
>> performed independently (i.e., they were validated), what's useful
>> from the pov of the reader is to get the aggregate of the tests,
>> possibly in a table.
>> 
>> If all the overlapping text shielded the same result, please say
>> so, and just publish the aggregate of the results. If the same test
>> shielded a different result in each of the test scenarios, please
>> note which ones, and try to explain why the same test shielded a
>> different result.
> [Bing] Good point, thanks. The two tests were partial overlapped, and
> the overlapped part was consistent in results. We just aggregated the
> results as Section 4, and keep the raw details of the two tests in
> the Appendix. When people read the document, we assume it is
> sufficient to get aware of the problems from the main body text; and
> if somebody interested in the test details, then he/she could get it
> in the Appendix. Do you think it's ok?

I'd just keep the aggregate results. i.e., if both independent test
shielded the same results, then there's no need to provide details about
the two testing setups.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 24 Feb 2016 08:12:19 +0000

Hi Fernando,

> >> ** Technical **
> >>
> >> * Section 1, page 3:
> >>> The M and O flags are advisory, not prescriptive.  For example, the
> >>> M flag indicates that addresses are available from DHCPv6, but It
> >>> does not indicate that hosts are required to acquire addresses from
> >>> prescriptive in implementations according to the test results in the
> >>> appendix.)
> >>
[Bing] No problem, will do.

> >> different things (i.e., no overlap, partial overlap, or full overlap
> >> of the tests).
> >>
> >> independently (i.e., they were validated), what's useful from the pov
> >> of the reader is to get the aggregate of the tests, possibly in a
> >> table.
> >>
> >> If all the overlapping text shielded the same result, please say so,
> >> and just publish the aggregate of the results. If the same test
> > results as Section 4, and keep the raw details of the two tests in the
> > Appendix. When people read the document, we assume it is sufficient to
> > get aware of the problems from the main body text; and if somebody
> > interested in the test details, then he/she could get it in the
> > Appendix. Do you think it's ok?
> 
> I'd just keep the aggregate results. i.e., if both independent test shielded the
> same results, then there's no need to provide details about the two testing
> setups.
[Bing] Ok, I'll try to eliminate the redundant cases of the two testing setups. Thanks.

Best regards,
Bing