Subject: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12

From: Christian Huitema <[email-masked]>
Date: Sun, 06 Jan 2019 22:27:23 -0800

Reviewer: Christian Huitema
Review result: Ready

I already reviewed the version 11 of this draft. From a security point of view,
the main change between the two versions is the addition of a paragraph
acknowledging the potential risks of relying on DHCP for configuration. To
quote: "As described in [RFC8026] and [RFC8026] Security Consideration
sections, there are generic DHCP security issues, which in the case of this
document means that malicious nodes may alter the priority of the transition
mechanisms."

Well, on the one hand, this does directly address the point I raised in the
previous review. On the other hand, it is a bit sad to have a dry
acknowledgement like that, without any hint at mitigations. If I was writing an
April's fool RFC, I would qualify that as one of those security sections that
seem written primarily for appeasing the security reviewer. But then, do we
want to give some advice to implementers? For example, do we want to tell them
that it is OK to deploy compliant devices in a basic home network? Probably. In
the branch office of a financial institution? Most probably not. Do we have a
way to convey that in simple terms? I would add something like:

"As stated in the introduction, this document addresses deployment of IPv4 as a
service in a residential or small-office network. Deployment in more
challenging environments would require additional security analysis."

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 07 Jan 2019 11:16:32 +0100

Hi Christian,

Thanks for your review.

There is a typo there, wrong copy and paste. It should be RFC8415 and RFC8026, as we discussed after your review.

My point, as discussed in the previous email exchange, is that this is a generic issue of DHCP. DHCP is used by both residential and non-residential service provisioning, and I don't see how we can solve that problem unless we implement some new DHCP "extension" that apply end-to-end encryption between, in this case, the CEs and the servers.

I can have a security section with basically replicates the text available in RFC8415 Security Section, including considerations of using IEEE-802.1X, DHCP snooping/guard/access control mechanisms, use of TR-069 access control mechanisms, etc.

I'm also happy to add your suggested paragraph regarding additional security analysis in more challenging environments.

Or maybe the correction of the RFC8415 references is sufficient in your opinion or you will prefer some additional text to summarize the RFC8415 security considerations/mitigations?

I'm going to wait a couple of days, in case there are further inputs, before uploading a new version correcting the mistake and also take in considerations the suggestions from the Gen-ART review a couple of days ago.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Christian Huitema <[email-masked]>
Fecha: lunes, 7 de enero de 2019, 7:28
Para: <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>
Asunto: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12

    

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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 07 Jan 2019 11:38:33 +0100

Hi Christian,

I've drafted this at the moment. Let me know if you think now this is better and if you think anything else is needed.

8.  Security Considerations

   The IPv6 Transition CE Router must comply with the Security
   Considerations as stated in [RFC7084], as well as those stated by
   each transition mechanism implemented by the IPv6 Transition CE
   Router.

   As described in [RFC8026] and [RFC8415] Security Consideration
   sections, there are generic DHCP security issues, which in the case
   of this document means that malicious nodes may alter the priority of
   the transition mechanisms.

   Considering that, networks using DHCPv6, depending on their specific
   topologies, should consider using authentication mechanisms such as
   those based on IEEE-802.1X or access control mechanisms such as DHCP
   snooping, DHCP guard, or TR-069, among other possible choices.

   As stated in the introduction, this document addresses deployment of
   IPv4aaS in residential, SOHO and SME networks.  Deployment in more
   challenging environments would require additional security analysis.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Fecha: lunes, 7 de enero de 2019, 11:17
Para: Christian Huitema <[email-masked]>, <[email-masked]>
CC: <[email-masked]>, <[email-masked]>
Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12

    Hi Christian,
    
    Thanks for your review.

    

    
    
    Regards,
    Jordi

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Jan 2019 10:02:19 -0800

Yes, that would work fine. If it could help convince these routers to implement DHCP guard or RA guard, that would be a great result.

I am not so sure about 802.1x. The routers could of course support a setting like that of the IETF network, and that would have some advantage over WPA residential, but it would not address an important threat: local device compromised by some virus and engaging in DHCP spoofing. DHCP guard or RA guard would still be needed.

-- Christian Huitema 

> On Jan 7, 2019, at 2:38 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi Christian,
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 7 Jan 2019 19:17:01 +0000

> From: v6ops <[email-masked]> On Behalf Of Christian Huitema
...
> I am not so sure about 802.1x. The routers could of course support a setting
> like that of the IETF network, and that would have some advantage over
> WPA residential, but it would not address an important threat: local device
> compromised by some virus and engaging in DHCP spoofing. DHCP guard or
> RA guard would still be needed.

802.1X is very widely used in GPON and DSL networks and I haven't heard of it having any issues. I'm not understanding the reference to WPA and local devices, since I think we're talking about the WAN and not the LAN interface here? 

..........
> > On Jan 7, 2019, at 2:38 AM, JORDI PALET MARTINEZ
...
> >   snooping, DHCP guard, or TR-069, among other possible choices.

TR-069 is a management protocol (that goes over HTTP, using TLS for security), and not an access control mechanism. I suggest it be removed from this list.

Barbara

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 07 Jan 2019 20:58:10 +0100

Hi Barbara,

I agree with your regarding the WPA, not sure to understand the point from Christian.

If a local device is compromised, that happens in the LANs and this will only affect the CE, if the "virus" or "bot" or whatever is able to compromise the CE configuration and then replace some of the settings done by the provisioning system.

This is something that may happen regardless of using DHCP in the WAN or other protocols.

I recall having seen some TR-069 mechanism (maybe it was proprietary) to provide something related to access control security, but if it is not standard, I will remove it. Let's see if someone in the list can provide some info and I will also try to recall what was in the case I've in mind.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de "STARK, BARBARA H" <[email-masked]>
Fecha: lunes, 7 de enero de 2019, 20:20
Para: 'Christian Huitema' <[email-masked]>, JORDI PALET MARTINEZ <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: RE: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12

    ...

    ..........
    ...

    Barbara

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Jan 2019 20:13:58 -0800

> I recall having seen some TR-069 mechanism (maybe it was proprietary) to provide something related to access control security, but if it is not standard, I will remove it. Let's see if someone in t…

Maybe I was not clear. I am not overly concerned with what happens on
the WAN side -- I assume that the ISP deploying customer premise devices
will find a way to provision them securely. I am concerned that using
DHCPv6 to provision networking parameters on the local hosts exposes
these hosts to generic DHCP spoofing attacks. To mount the DHCP spoofing
attacks, the attacker will need to either gain connectivity to the local
network, or gain controlled of a local device. Access control protocols
like 802.1x will prevent unauthorized devices from connecting to the
local network; they will not close the second avenue of attack,
something that solutions like DHCP guard would do.

The local router can filter which packets are relayed between Wi-Fi
devices, and can filter out spoofed DHCP packets. That's reasonably easy
to deploy in small networks, where the only authorized DHCP server is
located on the router itself. Of course, the current document is not
meant as a general home router requirement draft -- it just specifies
the narrow problem of how these routers should facilitate deployment of
IPv4 as a service. I do like Jordi's succession to refer to DHCP Guard
as a potential mitigation of DHCPv6 issues, because it can be deployed
simply and it would thwart a series of potential attacks.

I am less enthusiastic about 802.1x, because as I said above it
addresses a fraction of the problem, but not the whole problem. Standard
deployment of 802.1x requires an authentication server, which currently
does not come with small routers. It also requires management of this
authentication server, which is a tall order in these small networks.
There have been attempts to define a simpler profile of 802.1x, in which
all users have the same ID and the same password -- such as what is used
in the IETF Wi-Fi networks. This does improve somewhat over the
residential version of WPA, in which all users share the same "Wi-Fi
password", because it provides better isolation between users. But I
would have a hard time recommending 802.1x deployment in residential
networks "because of DHCPv6 security".

While I do like the "DHCP Guard" class of solutions, I am also concerned
that the DHCP Guard concept is only defined by the commercial literature
of some vendors -- and the same goes for DHCP Snooping, which could have
a variety of meanings. If you want to use that term, then you should add
a reference to the paper where this is defined. Or you could use neutral
language, like:

  Considering that, networks using DHCPv6, depending on their specific
  topologies, should consider using access control mechanisms such as
  those based on IEEE-802.1X, and DHCPv6 filtering mechanisms designed to
  prevent forwarding of spoofed DHCPv6 packets through the router, often
  referred to as "DHCP Guard."

I am also skeptical of the mention of "SME" in the last paragraph, in
"deployment of IPv4aaS in residential, SOHO and SME networks". The
definition of what is a small or medium enterprise varies by countries.
In the European Union, it is up to 250 employees. In the US, it is
defined by revenues and employees limit, typically fewer than 500
employees. In other part of the world, it can be fewer than 50
employees, or maybe it is just defined by a limit on revenues. In any
case, I would personally be reluctant to deploy simple devices like
described in the draft in a network with 100 to 200 people, let alone
500. That would be pushing luck a bit too far.

The introduction of the draft says "This document defines IPv4 service
continuity features over an IPv6-only network, for a residential or
small-office router..." I would suggest using exactly the same language,
as in:

  As stated in the introduction, this document addresses deployment of
  IPv4aaS in residential or small-office networks.  Deployment in more
  challenging environments would require additional security analysis.

-- Christian Huitema

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 08 Jan 2019 09:44:11 +0100

Hi Christian,

While I'm sympathetic with all what you said, this document is not adding/changing anything regarding the LAN-side configuration related to DHCP, and from that perspective, we refer to what is already required by RFC7084, which in turn calls to RFC6092.

If I recall correctly, RFC6092 doesn't say anything about DHCP/RA security.

I see SMEs with hundreds of employees, using this kind of routers connected to 600 Mbps FTTH symmetric links (Spain, but I'm sure is the same case in many other countries). However, in those cases, the router is only used a "pure router", and there is a server(s) providing DHCP, NAT, firewall, etc., switches (which in many cases do DHCP-guard features as well as RA-Guard).

The reason for it, is that those organizations don't have a "critical" need to connect to internet (if it fails a few hours is not a problem, they don't host internal services to be accessed from Internet), or even it is much cheaper to have 2 or 3 of those links (in Spain the cost is about 40 Euros per month, including flat rate VoIP for national calls, any kind of failure needs to be fixed in a maximum of 24 hours, by law, while typically is less than 8 hours) for backup/load balancing.

If they choose a "corporate" link type, they will get a "business" router, the link is the same (connecting to the same access/core infrastructure), just they get a "promise" of a better SLA, but then they will need to pay 400 Euros/month for the link.

Anyway, I agree with the suggested changes, as it doesn't harm if we don't explicitly say in the security section that the text is related to the LAN or WAN side. Is up to the implementor in this case, to decide if they want to offer a "better" CE firmware supporting those additional features.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Christian Huitema <[email-masked]>
Fecha: martes, 8 de enero de 2019, 6:04
Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>, "STARK, BARBARA H" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12

    

    

    
    
    -- Christian Huitema

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 8 Jan 2019 17:14:49 +0000

> Maybe I was not clear. I am not overly concerned with what happens on the
> WAN side -- I assume that the ISP deploying customer premise devices will
> find a way to provision them securely. I am concerned that using
> network, or gain controlled of a local device. Access control protocols like
> 802.1x will prevent unauthorized devices from connecting to the local
> network; they will not close the second avenue of attack, something that
> solutions like DHCP guard would do.

I agree completely that 802.1X is irrelevant to the types of LANs the CE routers described by this draft are used in, and shouldn't be mentioned in reference to the LAN interfaces of these CE routers.
However, IMO, the security section should be discussing security concerns that arise specifically as a result of the requirements in the draft. Concerns that are independent of these requirements are out of scope. AFAICT, none of the requirements in this draft create/enable new threats or attack vectors related to LAN DHCP spoofing attacks; therefore LAN DHCP spoofing attacks (discussing them and proposing how to address them) are out of scope.
 
> The local router can filter which packets are relayed between Wi-Fi devices,
> and can filter out spoofed DHCP packets. That's reasonably easy to deploy in
> small networks, where the only authorized DHCP server is located on the
> router itself. Of course, the current document is not meant as a general
> home router requirement draft -- it just specifies the narrow problem of how
> these routers should facilitate deployment of
> IPv4 as a service. I do like Jordi's succession to refer to DHCP Guard as a
> potential mitigation of DHCPv6 issues, because it can be deployed simply and
> it would thwart a series of potential attacks.

Intra-LAN routing/bridging/switching/filtering/relaying is out of scope of this draft. Intra-LAN behaviors are not relevant to IPv4aaS. There is no mention of LAN-side DHCPv6 (or DHCPv4) in the draft. All mention of DHCPv6 is WAN interface DHCPv6 client behavior. DHCP(v6) guard isn't a client behavior. I don't like Jordi's suggested text, because (1) as a WAN behavior (which is how most people will interpret it) DHCP guard makes no sense, and (2) as a LAN behavior it's out of scope. 

> I am less enthusiastic about 802.1x, because as I said above it addresses a
> fraction of the problem, but not the whole problem. Standard deployment of
> 802.1x requires an authentication server, which currently does not come with
> small routers. It also requires management of this authentication server,
> which is a tall order in these small networks.
> There have been attempts to define a simpler profile of 802.1x, in which all
> users have the same ID and the same password -- such as what is used in the
> IETF Wi-Fi networks. This does improve somewhat over the residential
> version of WPA, in which all users share the same "Wi-Fi password", because
> it provides better isolation between users. But I would have a hard time
> recommending 802.1x deployment in residential networks "because of
> DHCPv6 security".
> 
> While I do like the "DHCP Guard" class of solutions, I am also concerned that
> the DHCP Guard concept is only defined by the commercial literature of
> some vendors -- and the same goes for DHCP Snooping, which could have a
> variety of meanings. If you want to use that term, then you should add a
> reference to the paper where this is defined. Or you could use neutral
> language, like:
> 

There are no expectations expressed either in this draft or RFC 7084 (which this draft builds upon) that the CE router might be forwarding (or relaying) DHCPv6 packets through the router. RFC 7084 requires the CE router to have its own WAN-facing DHCPv6 client. If it wants to support any sort of LAN-side DHCPv6, it SHOULD have a DHCPv6 server. Nothing about forwarding or relaying. Again, I contend that discussing DHCP Guard in the Security section is out of scope.

Barbara

> In the European Union, it is up to 250 employees. In the US, it is defined by
> revenues and employees limit, typically fewer than 500 employees. In other
> part of the world, it can be fewer than 50 employees, or maybe it is just
> defined by a limit on revenues. In any case, I would personally be reluctant to
> deploy simple devices like described in the draft in a network with 100 to 200
> people, let alone 500. That would be pushing luck a bit too far.
> 
> continuity features over an IPv6-only network, for a residential or small-
> office router..." I would suggest using exactly the same language, as in:
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 08 Jan 2019 19:38:30 +0100

Hi Barbara,

The security concerns raised *initially* by Christian were related to the use of DHCP for configuring the WAN. At least that was what I understood. Then we continued discussing about the LAN, which I agree with you, is not a requirement on this document.

I guess the right way to approach this will be to update RFC6092 with new minimum security requirements, but this is out of the scope of this thread.

This is what I'm proposing, making sure that we are speaking about the DHCPv6 requirements from this document, but at the same time remembering that the LAN side is also important (but not in the scope of this document):

   Considering that, networks using DHCPv6 as indicated in this document, 
   depending on their specific topologies, should consider using access
   control mechanisms such as those based on IEEE-802.1X, and
   DHCPv6 filtering mechanisms designed to prevent forwarding
   of spoofed DHCPv6 packets to the IPv6 Transition CE, often
   referred to as "DHCP Guard". Those can be used as well, in the 
   LAN side, but this is out of the scope of this document.

   As stated in the introduction, this document addresses deployment of
   IPv4aaS in residential or SOHO networks.  Deployment in more
   challenging environments would require additional security analysis.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de "STARK, BARBARA H" <[email-masked]>
Fecha: martes, 8 de enero de 2019, 18:16
Para: 'Christian Huitema' <[email-masked]>, JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12

     

    
    
    Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 8 Jan 2019 19:28:20 +0000

> The security concerns raised *initially* by Christian were related to the use of
> DHCP for configuring the WAN. At least that was what I understood. Then we
> continued discussing about the LAN, which I agree with you, is not a
> requirement on this document.
> 
> I guess the right way to approach this will be to update RFC6092 with new
> minimum security requirements, but this is out of the scope of this thread.
> 
> This is what I'm proposing, making sure that we are speaking about the
> DHCPv6 requirements from this document, but at the same time
> remembering that the LAN side is also important (but not in the scope of this
> document):
> 

How access networks secure their infrastructure is specific to that access network's architecture. Access network architectures are specified by orgs such as 3GPP, CableLabs, and BBF. In the context of some access network architectures, 802.1X is not the solution that is used, and IETF shouldn't be suggesting they use it. I'm not aware of any that use "DHCPv6 filtering mechanisms" or "DHCP Guard". Most tend to use much more extreme separation of customer traffic. And if an ISP's own managed network elements are compromised, "DHCP Guard" is not the answer -- identifying the compromised network element and removing it from the network is the answer. Which makes this recommendation illogical and inappropriate. Access network architecture is not in scope of this draft. If you really want the paragraph about generic DHCP security issues, I would suggest adding something like this at the end: "Access network architecture for securing DHCP within the access network is out of scope of this document. Securing DHCP in the LAN is also not in scope. DHCP packets MUST NOT be forwarded between LAN and WAN interfaces of an IPv6 Transition CE router." And delete the last 2 paragraphs.
Barbara

> Para: 'Christian Huitema' <[email-masked]>, JORDI PALET MARTINEZ
> <jordi.palet=[email-masked]>
> the
>     I agree completely that 802.1X is irrelevant to the types of LANs the CE
> routers described by this draft are used in, and shouldn't be mentioned in
> reference to the LAN interfaces of these CE routers.
>     However, IMO, the security section should be discussing security concerns
> that arise specifically as a result of the requirements in the draft. Concerns
> that are independent of these requirements are out of scope. AFAICT, none
> of the requirements in this draft create/enable new threats or attack vectors
> related to LAN DHCP spoofing attacks; therefore LAN DHCP spoofing attacks
> (discussing them and proposing how to address them) are out of scope.
> 
> devices,
>     Intra-LAN routing/bridging/switching/filtering/relaying is out of scope of
> this draft. Intra-LAN behaviors are not relevant to IPv4aaS. There is no
> mention of LAN-side DHCPv6 (or DHCPv4) in the draft. All mention of DHCPv6
> is WAN interface DHCPv6 client behavior. DHCP(v6) guard isn't a client
> behavior. I don't like Jordi's suggested text, because (1) as a WAN behavior
> (which is how most people will interpret it) DHCP guard makes no sense, and
> (2) as a LAN behavior it's out of scope.
> 
> all
> that
>     There are no expectations expressed either in this draft or RFC 7084 (which
> this draft builds upon) that the CE router might be forwarding (or relaying)
> DHCPv6 packets through the router. RFC 7084 requires the CE router to have
> its own WAN-facing DHCPv6 client. If it wants to support any sort of LAN-side
> DHCPv6, it SHOULD have a DHCPv6 server. Nothing about forwarding or
> relaying. Again, I contend that discussing DHCP Guard in the Security section
> is out of scope.
> 
>     Barbara
> 
>     https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=gGwusfSCUjkQieuNQ1I76yNz54321Lz8kiQpqHBBvu0&s
> =62NJj2nxHp7lZxf5iEft4SFZ9-mXPvqSAvZvhFbuOu0&e=
> 
> 
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.theipv6company.com&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=gGwusfSCUjkQieuNQ1I76yNz54321Lz8kiQpqHBBvu0&s
> =yRwfzC0UkeyWwWoC5LthWkGDDkAPSoqrNW2MZvFvN_o&e=
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of the
> individual(s) named above and further non-explicilty authorized disclosure,
> copying, distribution or use of the contents of this information, even if
> partially, including attached files, is strictly prohibited and will be considered a
> criminal offense. If you are not the intended recipient be aware that any
> disclosure, copying, distribution or use of the contents of this information,
> even if partially, including attached files, is strictly prohibited, will be
> considered a criminal offense, so you must reply to the original sender to
> inform about this communication and delete it.
> 
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 8 Jan 2019 22:13:02 -0800

> The security concerns raised *initially* by Christian were related to the use of DHCP for configuring the WAN. At least that was what I understood. Then we continued discussing about the LAN, which…

I may be very confused, because the way I read your draft I assumed that
the DHCPv6 S46 option was meant to inform the LAN-side devices of the
available and preferred transition services. From what you are telling
me, the S46 option is actually provided by the WAN side DHCPv6 server,
of which the CPE is a client. That would be the preferred way for an ISP
to configure the customer premise device.

If the DHCPv6 option is only used on the WAN side, then I agree with
Barbara and you that solutions like DHCP Guard or 802.1x are not
relevant. There is no need for the proposed paragraph starting with
"considering that" and ending with "scope of this document".

On the other hand, if I was that much confused, others will be too. I
might be useful to drop a line in section 3.2 explain in layman terms
how the S46 option is used.

-- Christian Huitema

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 09 Jan 2019 11:30:17 +0100

Hi Christian,

No, it was not intended to configure the LANs, just the CE.

I think that's clear in the document (abstract, intro), so if you feel that something else need to be included to make sure that is not misunderstood, please, let me know.

In Section 3.2 I've added this, let me know if you think is now clearer:

   Note that this document is only configuring the IPv4aaS in the IPv6
   Transition CE Router itself, and not forwarding such information to
   devices attached to the LANs, so the WAN configuration, availability
   of native IPv4 or IPv4aaS, is transparent for them.

Regarding the Security Section, following your points and Barbara suggestions I've this:

   Access network architecture for securing DHCP within the access
   network is out of scope of this document.  Securing DHCP in the LAN
   is also not in scope.  DHCP packets MUST NOT be forwarded between LAN
   and WAN interfaces of an IPv6 Transition CE router.

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Christian Huitema <[email-masked]>
Fecha: miércoles, 9 de enero de 2019, 7:14
Para: JORDI PALET MARTINEZ <[email-masked]>, "STARK, BARBARA H" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12

    

    -- Christian Huitema