Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags

["Liubing (Leo)" <[e-mail]>]

Hi Enno and all,

> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Enno Rey
> Sent: Thursday, May 14, 2015 10:51 PM
> To: [e-mail]
> Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O' flags
> 
> All,
> 
> pls allow to make you aware that we did some similar tests as those laid out
> in draft-ietf-v6ops-dhcpv6-slaac-problem (btw: very nice work!). Details &
> results can be found in:
> https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DH
> CPv6_Conflicting_Parameters.pdf.
[Bing] Thanks much for sharing the information. 
I'm very happy to see you've done RDNSS&DHCPv6-DNS_Option test and also the more complex scenarios with two routers on the same link. Those tests are really a nice step forward beyond the current v6ops draft.

Another very useful information from your report is the security considerations. Please allow me to quote some of them:
- "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."
- " If you want to perform MiTM using a rogue DNS while legitimate RAs with the O flag set are sent to enforce the use of a
DHCPv6 server, you can spoof RAs with the same settings with the legitimate prefix (in order to remain undetectable) but advertising YOUR (attacker's) DNS using RDNSS. In this case, Fedora 21, Centos 7 and Ubuntu 14.04 will use the rogue
RDNSS (advertised by the RAs) as a first option."
- " Fedora 21 and Centos 7 behaviour cannot be explored for a MiTM attack using a rogue DNS information either, since the
one obtained by the RAs of the first router has a higher priority."
- " 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."
- " The Fedora and Centos behaviour can also be exploited for MiTM purposes by advertising rogue RDNSS by RAs which
include RDNSS information."

I think these are essential cautions for the administrators to refer.

> We gave a presentation on this today in the IPv6 WG at RIPE70, with some
> additionals comments:
> https://ripe70.ripe.net/presentations/132-ERNW_RIPE70_IPv6_Behavior_Co
> nflicting_Environments_v0_92_short.pdf
[Bing] Very interesting and thoughtful presentation. Recommend all to have a read.

Best regards,
Bing

> Overall we observed the same unfortunate ambiguities and differing vendor
> interpretations/strategies.

> thanks
> 
> Enno
> 
> 
> On Thu, May 14, 2015 at 02:41:32PM +0000, Mudric, Dusan (Dusan) wrote:
> > Hi Bing,
> >
> > The draft-ietf-v6ops-dhcpv6-slaac-problem nicely captures ambiguities and
> different interpretations around 'M', 'O' and 'A' flags. It also opens a floor
> for further discussion around:
> > - the need for stateless DHCPv6,
> > - simultaneous SLAAC and DHCPv6 address assignments, and
> > - ND and DHCPv6 interworking: e.g. the role of ND on-link address prefix
> for DHCPv6 addresses.
> >
> > Only when the needs are systematically captured, it will be possible to
> define the flags.
> >
> > [Bing] (Speak as a co-author) We indeed didn't test the case as you said
> above, but we tested a similar case: at initial stage, when A=0,M=0, and O=1,
> some platform would start stateless DHCPv6 while some not.
> > [Dusan] Did the hosts run stateless DHCPv6, or stateful DHCPv6 without
> the address option in ORO, or stateful DHCPv6 and ignored the address in
> REPLY?
> >
> > > - Does not mention if the host is SLAAC and stateful DHCPv6
> > > configured simultaneously (bullet two does not say stateful), DHCPv6
> > > address should start with PI prefix
> > [Bing] Sorry I didn't catch your point. Why is the "PI prefix" related to
> SLAAC/DHCPv6 configured simultaneously?
> > Btw, which "bullet two" did you refer to?
> > [Dusan] It is important that DHCPv6 address starts with on-link prefix.
> Otherwise the end point will be unreachable. When SLAAC/DHCPv6 are
> configured to run simultaneously, if M=1 is interpreted to mean run stateful
> DHCPv6 and obtain IPv6 address via DHCPv6 client, PI option should have L
> bit set to allow the end point to verify the acquired DHCPv6 address in
> on-link. This behavior should be standardized.
> >
> > [Bing] Btw, which "bullet two" did you refer to?
> > [Dusan] Section 3 - 2).
> >
> > > - Does not mention that 'M' and 'O' flags, should be used as a
> > > mechanism to disable only stateful IPv6 address if SLAAC is enabled.
> > [Bing] Did you mean, when a host is configured with SLAAC, the DHCPv6
> address configuration should be disabled?
> > [Dusan] Yes, only the address part should be disabled. But other
> configuration information should be still available via DHCPv6.
> >
> > [Bing] However, personally I'm not sure this should be a right behavior.
> SLAAC/DHCPv6 addresses co-existing might make sense in some scenarios.
> > [Dusan] draft-liu-v6ops-running-multiple-prefixes-03#section-3.1 only talks
> about the prefix delivering mechanism to routers using DHCPv6. It does not
> recommend the co-existing SLAAC/DHCPv6 behavior for hosts. If there is a
> need for multiple IPv6 addresses per interface, as mentioned in the draft,
> SLAAC already allows the use of multiple prefixes and DHCPv6 already allows
> the assignment of multiple IPv6 addresses. There is really no need for adding
> further complexity by mixing the two: SLAAC IPv6 addresses and DHCPv6
> IPv6 addresses.
> >
> > > What is the value of
> > > disabling other DHCPv6 configuration? End point instruments need
> > > DHCPv6 for other configuration information and that shall not be
> > > disabled via a router (Unless there is a plan to provide all that
> configuration via a router?).
> > > If there is agreement on this statement, only one flag is needed, 'M' flag.
> > [Bing] I can't really answer this question. My guess is that , when the hosts
> can get both address and other configuration information through stateful
> DHCPv6 configuration, then the stateless DHCPv6 configuration is redundant
> if it is always on.
> > [Dusan] Stateless DHCPv6 is redundant by its nature. Stateful DHCPv6 can
> send SOLICIT and REQUEST messages with ORO option that does not require
> the address (e.g. without OPTION_IA_NA option code). If there is no
> stateless DHCPv6 client to control, there is no need for 'O' flag. The
> remaining 'M' flag can be used to control if ORO option has OPTION_IA_NA
> option code.
> >
> > Regards,
> > Dusan Mudric.
> >
> > -----Original Message-----
> > From: Liubing (Leo) [mailto:[e-mail]]
> > Sent: Wednesday, May 13, 2015 11:10 PM
> > To: Mudric, Dusan (Dusan); Brian E Carpenter; Lorenzo Colitti; STARK,
> > BARBARA H; [e-mail]
> > Cc: Lin, Ping (Ping); Steven B.
> > Subject: RE: Question re. stateless DHCPv6 and 'M' & 'O' flags
> >
> > Hi Dusan and all,
> >
> >
> >
> > > -----Original Message-----
> >
> > > From: v6ops [mailto:[e-mail]] On Behalf Of Mudric,
> > > Dusan
> >
> > > (Dusan)
> >
> > > Sent: Thursday, May 14, 2015 4:46 AM
> >
> > > To: Brian E Carpenter; Lorenzo Colitti; STARK, BARBARA H;
> > > [e-mail]
> >
> > > Cc: Lin, Ping (Ping); Steven B.
> >
> > > Subject: Re: [v6ops] Question re. stateless DHCPv6 and 'M' & 'O'
> > > flags
> >
> > >
> >
> > > draft-ietf-v6ops-dhcpv6-slaac-problem:
> >
> > > - Does not mention use of stateless DHCPv6
> >
> > > - Does not mention that is not clear if stateless DHCPv6 client
> > > should start if
> >
> > > SLAAC is used and M=0 and O changes from 0 to 1. Or, stateful DHCPv6
> > > can
> >
> > > start but IPv6 address can be ignored or ORO option does not require
> > > the
> >
> > > address.
> >
> > [Bing] (Speak as a co-author) We indeed didn't test the case as you said
> above, but we tested a similar case: at initial stage, when A=0,M=0, and O=1,
> some platform would start stateless DHCPv6 while some not.
> >
> > Details please refer to the Appendix A.2
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html
> _draft-2Dietf-2Dv6ops-2Ddhcpv6-2Dslaac-2Dproblem-2D04-23appendix-2D
> A.2&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIo
> UWB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl
> 4OmAPBz0&s=RYBX4oXn9Jb6D1f2S20unVfInYB3XQCyqBuchFII1-w&e= ).
> >
> >
> >
> > > - Does not mention if the host is SLAAC and stateful DHCPv6
> > > configured
> >
> > > simultaneously (bullet two does not say stateful), DHCPv6 address
> > > should
> >
> > > start with PI prefix
> >
> > [Bing] Sorry I didn't catch your point. Why is the "PI prefix" related to
> SLAAC/DHCPv6 configured simultaneously?
> >
> > Btw, which "bullet two" did you refer to?
> >
> >
> >
> >
> >
> > > - Does not mention that 'M' and 'O' flags, should be used as a
> > > mechanism to
> >
> > > disable only stateful IPv6 address if SLAAC is enabled.
> >
> > [Bing] Did you mean, when a host is configured with SLAAC, the DHCPv6
> address configuration should be disabled?
> >
> > We did observed some behaviors like this in some platform: when a host
> has configured SLAAC, and then M changes from 0 to 1, some hosts just
> ignore the M flag (see the second bullet of Appendix A.3).
> >
> >
> >
> > However, personally I'm not sure this should be a right behavior.
> SLAAC/DHCPv6 addresses co-existing might make sense in some scenarios.
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_
> draft-2Dliu-2Dv6ops-2Drunning-2Dmultiple-2Dprefixes-2D03-23section-2D3.
> 1&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoU
> WB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4mxdfBg7Uh-KZQfl4
> OmAPBz0&s=s5I7IrkUrSvi6Ev5mUhvri9GoL2pLI1Z2cWYDTEQOmM&e=  has
> a brief discussion on this. But this draft-ietf-v6ops-dhcpv6-slaac-problem
> does not intend to discuss what the right behavior should be.
> >
> >
> >
> > > What is the value of
> >
> > > disabling other DHCPv6 configuration? End point instruments need
> > > DHCPv6
> >
> > > for other configuration information and that shall not be disabled
> > > via a
> >
> > > router (Unless there is a plan to provide all that configuration via a
> router?).
> >
> > > If there is agreement on this statement, only one flag is needed, 'M' flag.
> >
> > [Bing] I can't really answer this question. My guess is that , when the hosts
> can get both address and other configuration information through stateful
> DHCPv6 configuration, then the stateless DHCPv6 configuration is redundant
> if it is always on.
> >
> >
> >
> > > This flag would control if end point instruments would have only
> > > SLAAC or
> >
> > > only DHCPv6 address (example: M=1 would mean only DHCPv6 address is
> >
> > > configured and if A=1 would mean that DHCPv6 address would have to
> > > start
> >
> > > with the PI prefix). I don't see a need for both SLAAC and DHCPv6
> addresses.
> >
> > [Bing] As said above, I think co-existing might make sense in some
> scenarios.
> >
> >
> >
> > Best regards,
> >
> > Bing
> >
> >
> >
> >
> >
> > > Dusan
> >
> > >
> >
> > > -----Original Message-----
> >
> > > From: Brian E Carpenter [mailto:[e-mail]]
> >
> > > Sent: Tuesday, May 12, 2015 4:05 PM
> >
> > > To: Mudric, Dusan (Dusan); Lorenzo Colitti; STARK, BARBARA H
> >
> > > Cc: Lin, Ping (Ping); Steven B.; [e-mail]; Bernie Volz (volz)
> >
> > > Subject: Re: Question re. stateless DHCPv6 and 'M' & 'O' flags
> >
> > >
> >
> > > Hi Dusan,
> >
> > >
> >
> > > The M/O flags are not obsolete. They are defined in RFC 4861.
> >
> > >
> >
> > > You might want to read
> >
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_
> > > html_
> >
> > >
> draft-2Dietf-2Dv6ops-2Ddhcpv6-2Dslaac-2Dproblem&d=AwIFaQ&c=BFpWQ
> >
> > >
> w8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2k
> >
> > >
> Y&m=APhD5Tq7Q9EZ64eDKTcooJX8vvQdTCdwGe7w--QcC30&s=VvC2nQToB
> >
> > > 51qdh8J7Jlpw-Y3NE3g_JSuooay2fEVu0s&e=
> >
> > > (noting that it is still a draft, discussed in the v6ops WG) and you
> > > might move
> >
> > > this discussion to the v6ops list, too.
> >
> > >
> >
> > > Regards
> >
> > >    Brian Carpenter
> >
> > >
> >
> > >
> >
> > > On 13/05/2015 06:53, Mudric, Dusan (Dusan) wrote:
> >
> > > > Hi Everyone,
> >
> > > >
> >
> > > > I would appreciate your help answering the questions regarding the
> >
> > > stateless DHCPv6 and ???M??? & ???O??? flags:
> >
> > > >
> >
> > > > Background:
> >
> > > > ===========
> >
> > > > Following RFC 2462, ???O??? flag in Router Advertisements is used
> > > > to start
> >
> > > stateless DHCPv6 client. When using ???O??? flag, the end point shall
> support:
> >
> > > >
> >
> > > > ??         RFC
> >
> > >
> 3736<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.rfc-2Deditor.
> >
> > >
> org_in-2Dnotes_rfc3736.txt&d=AwIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=
> >
> > >
> UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=APhD5Tq7Q9EZ64
> >
> > >
> eDKTcooJX8vvQdTCdwGe7w--QcC30&s=mZkhBdhXoIRGEsK6Z3mfWS4RyvKB
> >
> > > -IiKhorpXBfnwEY&e= > , that defines stateless DHCPv6 client
> >
> > > >
> >
> > > > ??         RFC 4242, that defines when the end point should refresh
> the
> >
> > > configuration information.
> >
> > > >
> >
> > > > Questions:
> >
> > > > =========
> >
> > > > If RFC 4862 removed ???M??? & ???O??? flags and obsoleted RFC 2462
> > > > (that
> >
> > > defines ???M??? & ???O??? flags), why are the flags not deprecated?
> > > What is the
> >
> > > value of referring to the obsoleted standard, in order to support
> > > flags in the
> >
> > > solution that is not mature?
> >
> > > >
> >
> > > > rfc4862#appendix-C
> >
> > > >    o  Removed the text regarding the M and O flags, considering
> > > > the
> >
> > > >       maturity of implementations and operational experiences.
> >
> > > >       ManagedFlag and OtherConfigFlag were removed accordingly.
> >
> > > (Note
> >
> > > >       that this change does not mean the use of these flags is
> >
> > > >       deprecated.)
> >
> > > >
> >
> > > > In the thread ???Re: Question re. RECONFIG in DHCPv6???, Bernie
> stated:
> >
> > > > ???The RFC 3736 document is really not something I would recommend
> >
> > > following - see full RFC 3315 and implement those features you need
> > > (such
> >
> > > as only Information-Request and Reply). 3736 was written to
> > > demonstrate
> >
> > > that stateless dhcpv6 was rather simple to implement.???
> >
> > > >
> >
> > > > Based on the fact that ???M??? & ???O??? flags are removed from
> > > > the RFC 4862
> >
> > > and the statement above, can we say the stateless DHCPv6 is not
> > > mandatory
> >
> > > and, consequently, ???O??? flag is not required?
> >
> > > >
> >
> > > > If stateless DHCPv6 is not used, stateful DHCPv6 is required.
> Then, ???M???
> >
> > > flag is not needed.
> >
> > > >
> >
> > > > Regards,
> >
> > > > Dusan Mudric.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > ------------------------------------------------------------------
> > > > --
> >
> > > > IETF IPv6 working group mailing list
> >
> > > > [e-mail]
> >
> > > > Administrative Requests:
> >
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> > > > mail
> >
> > > >
> >
> > >
> man_listinfo_ipv6&d=AwIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbL
> >
> > > eaJxhf3
> >
> > > >
> >
> > >
> iCrhIoUWB8YLZU23029sMQGQ2kY&m=APhD5Tq7Q9EZ64eDKTcooJX8vvQdT
> >
> > > CdwGe7w--Qc
> >
> > > > C30&s=4hQwBk4MvPSWFh7Lbyj9pLYa4obbbDO_17EYLcFKh3U&e=
> >
> > > > ------------------------------------------------------------------
> > > > --
> >
> > > >
> >
> > >
> >
> > > _______________________________________________
> >
> > > v6ops mailing list
> >
> > > [e-mail]
> >
> > >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma
> > >
> ilman_listinfo_v6ops&d=AwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9
> cbLea
> > >
> Jxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=m8AjAxL16hPwX4stNLi4mxdfBg
> 7Uh-KZQ
> > > fl4OmAPBz0&s=QafF4zQi6WCRV1T1_KKL8_NbyioKh7ME9LTrEEqqiXs&e=
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> --
> Enno Rey
> 
> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49
> 6221 480390 - Fax [phone] - Cell [phone]
> 
> Handelsregister Mannheim: HRB 337135
> Geschaeftsfuehrer: Enno Rey
> 
> =======================================================
> Blog: www.insinuator.net || Conference: www.troopers.de
> Twitter: @Enno_Insinuator
> =======================================================
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops