Softwire Provisioning using DHCPv4 Over DHCPv6
draft-ietf-dhc-dhcp4o6-saddr-opt-08

Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.

Eric Rescorla Discuss

Discuss (2018-10-10 for -06)
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5110


I believe there are security issues as detailed in this review.

DETAIL
S 9.
>      For such an attack to be effective, the attacker would need to know
>      both the client identifier and active IPv4 address lease currently in
>      use by another client.  The risk of this can be reduced by using a
>      client identifier format which is not easily guessable, e.g., by
>      including a time component for when the client identifier was
>      generated (see [I-D.ietf-dhc-rfc3315bis] Section 11.2).

This doesn't seem like a very strong defense. At minimum you need an
analysis of the level of entropy.

I note that an on-path attacker (as RFC 3552 requires us to consider)
will have no real problem with this attack. This seems fairly serious.
Comment (2018-10-10 for -06)
S 1.
>      A dynamic provisioning model, such as using DHCPv4 over DHCPv6
>      [RFC7341] (DHCP 4o6) allows much more flexibility in the location of
>      the IPv4-over-IPv6 softwire source address.  In this model, the IPv6
>      address is dynamically communicated back to the service provider
>      allowing the corresponding softwire configuration to be created in
>      the border router (BR).

I'm sure this is obvious to the informed, but it would have helped me
to have explained that the setting here is that the client has v6-only
service and is going to get a v4 address and tunnel that over v6.


S 5.
>              OPTION_DHCP4O6_S46_SADDR (TBD2) with the IPv6 address which
>              the client will use as its softwire source address.
>   
>      Step 4  The server sends a DHCPv6 'DHCPV4-RESPONSE (21)' message.
>              OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message.
>              OPTION_DHCP4O6_S46_SADDR with the client's softwire source

Which of these messages contains the client's assigned IPv4 address?
It's the DHCPOFFER, right?

Suresh Krishnan Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2018-10-10 for -06)
I agree with Alissa's comment privacy comment.

Please consider using the new normative keyword boilerplate from RFC 8174.

Alissa Cooper No Objection

Comment (2018-10-10 for -06)
I think this document could benefit from some discussion of the privacy considerations associated with the new options specified in the document. E.g., if one were to apply the analysis in RFC 7844, what would the guidance be to clients that want to limit the disclosure of information about themselves? (It might be "don't use DHCP4o6," but even that is worth saying if that's the best advice available.)

Spencer Dawkins No Objection

Benjamin Kaduk No Objection

Comment (2018-10-10 for -06)
Section 7

   It is also a prerequisite that the client has already learned a
   suitable IPv6 prefix to use for its local softwire endpoint using
   DHCPv6, RA/PIO or another mechanism.

I think I'm confused.  Is the OPTION_S46_BIND_IPV6_PREFIX option a way to
obtain the "suitable IPv6 prefix" above?  If so, then "prerequisite" may
not be the best word to use here.

Section 7.2.1

   Across the lifetime of the leased IPv4 address, it is possible that
   the client's IPv6 will change.  E.g., if there is an IPv6 re-
   numbering event.

nit: The last sentence is a sentence fragment.

Section 9

With address-binding mechanisms such as these we also try to consider the
possibility of binding an unexpected address to an unsuspecting recipient,
e.g., to direct a large flow of traffic to a victim unable to process it
all.  I did not see an immediate way for an attacker to do this, since it
would seem like it would either require DHCPv4 to assign the same address
twice or allow a duplicate v6/v4 softwire binding, but I am not sure I have
the full picture in my head yet.  It would be good to include some text on
this class of attacks, even if it is just "redirecting existing flows to an
unsuspecting victim is not possible because <reason>".

Mirja Kühlewind No Objection

Alexey Melnikov No Objection

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2018-10-10 for -06)
Thanks to everyone involved for the work they did on this document.

I agree with Alissa's request for the addition of privacy considerations.

---------------------------------------------------------------------------

§7.2.1:

>  the client's IPv6 will change.  E.g., if there is an IPv6 re-

Nit: "...the client's IPv6 address will change."

---------------------------------------------------------------------------

§9:

>  For such an attack to be effective, the attacker would need to know
>  both the client identifier and active IPv4 address lease currently in
>  use by another client.  The risk of this can be reduced by using a
>  client identifier format which is not easily guessable, e.g., by
>  including a time component for when the client identifier was
>  generated (see [I-D.ietf-dhc-rfc3315bis] Section 11.2).

I might be missing something here, but my understanding is that DHCP isn't
confidential, and so attackers on the same segment might be able to observe
another client's identifier and IPv4 address in the DHCP traffic itself
(depending on the nature of the networking equipment). Even if
this cannot be easily mitigated, I think it's worth mentioning.

---------------------------------------------------------------------------

§10:

>  IANA is requested to update the entry for DHCPv6 Option S46_BR (90)
>  in the Option Codes table at https://www.iana.org/assignments/
>  dhcpv6-parameters as follows:
>
>  Old entry:
>
>  |    90 | S46_BR                  | No                  | No        |
>
>  New entry:
>
>  |    90 | S46_BR                  | Yes                 | No        |

This is a somewhat unconventional way to represent IANA actions. This format
does not make sense in a vacuum; and, more importantly, and will lose meaning
in the case that the corresponding registry table is ever expanded. I also
note that the name is incorrect (S46_BR instead of OPTION_S46_BR), and that
the Reference column is omitted (which is relevant, as I believe the intenion
is to instruct IANA to add this document to the list of references).  Please
consider reformatting as:

  Old Entry:

    Value:             90
    Description:       OPTION_S46_BR
    Client ORO:        No
    Singleton Option:  No
    Reference:         [RFC7598]

  New Entry:

    Value:             90
    Description:       OPTION_S46_BR
    Client ORO:        Yes
    Singleton Option:  No
    Reference:         [RFC7598] [RFCxxxx]


>  IANA is also requested to make a new entry for
>  OPTION_S46_BIND_IPV6_PREFIX (TBD1) in the Option Codes table at
>  https://www.iana.org/assignments/dhcpv6-parameters:
>
>  |  TBD1 |OPTION_S46_BIND_IPV6_PREFIX| Yes               | Yes       |

Similarly:

    Value:             TBD1
    Description:       OPTION_S64_BIND_IPV6_PREFIX
    Client ORO:        Yes
    Singleton Option:  Yes
    Reference:         [RFCxxxx]

Warren Kumari No Record

Terry Manderson No Record

Martin Vigoureux No Record