[dhcwg] FW: Eric Rescorla's Discuss on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)

<ian.farrer@telekom.de> Tue, 30 October 2018 10:02 UTC

Return-Path: <ian.farrer@telekom.de>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F40912F1AB for <dhcwg@ietfa.amsl.com>; Tue, 30 Oct 2018 03:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level:
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1ZsY8wBlweQ for <dhcwg@ietfa.amsl.com>; Tue, 30 Oct 2018 03:02:55 -0700 (PDT)
Received: from mailout11.telekom.de (MAILOUT11.telekom.de [194.25.225.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AED128DFD for <dhcwg@ietf.org>; Tue, 30 Oct 2018 03:02:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1540893774; x=1572429774; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R1n+SYuDqG9PbvY3iUIIOK88ovCu10s8539ax9YRRgE=; b=fgBB/O4PRgvf0gVD/sVrbJ3g6MBj48EpvOrWq+Tk/NjIF/Lm0QGD9rG/ 9xUp2YennVHjvBCVnj5vA/M4ih0K96/1pd9Tl9NaHAjmhiqU6QFEIxAXA 2Jr9eOOgqMLGEG7gCO+GAPSA0KPJHhXE+Evn80tKkCzcrxnpbOTK7AZ8v RDSGM0sukBIRkY4aLTZUP3PqX7cCYMUue99xnUGFckW+3AOs5oqr8HZyc 9qVGPhjwLvBQH9Ot538lbjtwk/XXQHd8s967BWgseEg9iGLRDJ45nm+JG 3d55AnavR9DbBKIHhHZNyFZuy8hMvmmmYA5AaO+5MjmJIqmurzvybmXSJ g==;
Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT11.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 11:02:51 +0100
X-IronPort-AV: E=Sophos;i="5.54,444,1534802400"; d="scan'208,217";a="915693286"
Received: from he105780.emea1.cds.t-internal.com ([10.169.118.26]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 30 Oct 2018 11:02:06 +0100
Received: from HE105664.EMEA1.cds.t-internal.com (10.169.118.61) by HE105780.emea1.cds.t-internal.com (10.169.118.26) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Oct 2018 11:02:05 +0100
Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105664.EMEA1.cds.t-internal.com (10.169.118.61) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 30 Oct 2018 11:02:05 +0100
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.23) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 30 Oct 2018 11:01:51 +0100
Received: from FRXPR01MB0661.DEUPRD01.PROD.OUTLOOK.DE (10.158.154.13) by FRXPR01MB0663.DEUPRD01.PROD.OUTLOOK.DE (10.158.154.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.27; Tue, 30 Oct 2018 10:02:04 +0000
Received: from FRXPR01MB0661.DEUPRD01.PROD.OUTLOOK.DE ([fe80::a8e3:170c:2b46:cbed]) by FRXPR01MB0661.DEUPRD01.PROD.OUTLOOK.DE ([fe80::a8e3:170c:2b46:cbed%5]) with mapi id 15.20.1273.027; Tue, 30 Oct 2018 10:02:04 +0000
From: ian.farrer@telekom.de
To: ekr@rtfm.com
CC: dhcwg@ietf.org, draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.org
Thread-Topic: [dhcwg] Eric Rescorla's Discuss on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)
Thread-Index: AQHUYQf9AQ6GpaObekOZxUzLeQV1qaUbkMQAgAATQQCABPFxAIAXKHUA
Date: Tue, 30 Oct 2018 10:02:04 +0000
Message-ID: <4F4D8E4F-FB34-414F-BF84-1C4B58871345@telekom.de>
References: <153922397672.5804.489295934152877724.idtracker@ietfa.amsl.com> <1B1F17D2-5FAE-4FEC-93CE-F1D9CEFC08C4@telekom.de> <CABcZeBPeAfEVuLVTRbNjLYmKhNQJf9uyVEFSkn8ACKAo-RTMhw@mail.gmail.com> <01CCBF0B-BB55-43D2-9940-5F198F2190DB@telekom.de>
In-Reply-To: <01CCBF0B-BB55-43D2-9940-5F198F2190DB@telekom.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.3.181015
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.farrer@telekom.de;
x-originating-ip: [2003:1c09:21:c20:b5a4:f2da:fe55:add2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; FRXPR01MB0663; 6:zv0TqnTR349x7JkJZidSzeJTdlJ4zeza4kfnaZ8H6g+0u8dnrRakZ3m09DgFl5ciFG7ftwcXZWzhxTFzPgRx1GSKwqx60ZrejCPZLQmzoC0v97gvXFVW26YoayAlclSj0lx9T3PKnuAB1i3Mdp7Ho2SmqkZYUOvLCwk8ResFpCiSWJyfYiGgk1KbnLWz7uk3dRzrtzF2cC6Py3d1B52x8GKj0ZeovMj2GJtfhSCZNF55L61AVBoRMlBi7aV2cIXrSYmXqOZibv7cIZrmsRFaunydtjjgs9tt4bdeQxVBxqteo55R0jqr3BrTlP9OjyoJ70jauCFidEF9j0sYKBgNdDoDyWYwaI7SLSg6uIDt/S3voCdpy9o+NmVmXjXqZXNed1b1Z+Y1nwLpZvwmn/G3rJhHd/kqOtTDhqcLRLRVPRAsrubIqeCRQ2c7ov7TCUHabUK+XV590J7oRxHut6WytQ==; 5:JVhuXF4PAA+jJ342+oTVYa9vJwvXsA7VO3fE9M4+XFfOlS0KJcSqa6tDmu6PR6iKAb4u/1Huof3LF35r78xAbhTY6yMdwx3vjaZ+zEixX4xEC8UL1uSVOqVMc4L7kOsgMH8FOD8DyyUUMmMiAe5OTNjWyK2M7eeyKesOxLfijKc=; 7:YOiPwnSp2SD0v6YwbyDBIU0Vhv5Ya+Pahwr6+G8thB44iIuOXaZ0EOK/xWiEFQHThxVeNLe48hRJStcaGhC2kl2ooi4JopchJS6XYrgkk25UbXr7xc9RwsXpwkehyV1OocMGWkcQtVqMxmFAE3+H4w==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c705929b-a3c9-4357-4aef-08d63e4ebe9f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:FRXPR01MB0663;
x-ms-traffictypediagnostic: FRXPR01MB0663:
x-microsoft-antispam-prvs: <FRXPR01MB06635BE79D0E474C2ABC646DFCCC0@FRXPR01MB0663.DEUPRD01.PROD.OUTLOOK.DE>
x-exchange-antispam-report-test: UriScan:(260130700054247)(95692535739014)(158342451672863)(120809045254105)(192374486261705)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231382)(944501410)(52105095)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:FRXPR01MB0663; BCL:0; PCL:0; RULEID:; SRVR:FRXPR01MB0663;
x-forefront-prvs: 08417837C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(366004)(396003)(39860400002)(376002)(199004)(189003)(51914003)(53546011)(5250100002)(316002)(68736007)(97736004)(6916009)(75402003)(102836004)(52396003)(2900100001)(93886005)(606006)(186003)(229853002)(36756003)(966005)(14454004)(478600001)(7736002)(4326008)(76176011)(46003)(5660300001)(86362001)(6306002)(81166006)(105586002)(8936002)(2906002)(2473003)(6116002)(53936002)(54896002)(236005)(106356001)(2616005)(11346002)(33656002)(561944003)(114624004)(83716004)(446003)(476003)(54906003)(58126008)(21615005)(74482002)(256004)(71190400001)(14444005)(71200400001)(82746002)(8676002)(81156014)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB0663; H:FRXPR01MB0661.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-microsoft-antispam-message-info: F/MV6PmjkO6XU53wybgERXxHh76gyA2OrRfJqoEpVmehE3IRdmre+OWIw82RT0hMHH3KviysA0/EkLCJhxHVWL0CvNv3+SQdDlHzsnmvY7KhN+k+AaNYco16XxSz4OoR9GmG4GSqbU9Xueb35JmL+VqpLNmKDKxUVv9NR2hPbBevRywq6QWyKjmKW4qE6rU2w0ILoQyO6P2fOtH3ilas8/Fghk7+/LBhWqsZxnklD3QX5VIcYmLo/DX808ewJYpatVIib/A110BmdYj+/OTGCg4oBGk67flm/UrjAmjfVvhun0Fx8jk2Ql7faudRGn+oDxeYttqybFj62xBANX6lHAouGykrxE6hSgC6AKZXRxY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_4F4D8E4FFB34414FBF841C4B58871345telekomde_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c705929b-a3c9-4357-4aef-08d63e4ebe9f
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2018 10:02:04.4891 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB0663
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/kcz0s4uVU4L4BE1yz0b7qUaqgOM>
Subject: [dhcwg] FW: Eric Rescorla's Discuss on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2018 10:03:00 -0000

Hi Eric,

Did you have any thoughts on proposed updates below?

Many thanks,
Ian

From: Ian Farrer <ian.farrer@telekom.de>
Date: Monday, 15. October 2018 at 17:23
To: Eric Rescorla <ekr@rtfm.com>
Cc: IESG <iesg@ietf.org>, "draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.org" <draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.org>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Eric Rescorla's Discuss on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)

Hi Eric,

Thanks for the response. Please see inline below.

Regards,
Ian
From: Eric Rescorla <ekr@rtfm.com>
Date: Friday, 12. October 2018 at 15:55
To: Ian Farrer <ian.farrer@telekom.de>
Cc: IESG <iesg@ietf.org>, "draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.org" <draft-ietf-dhc-dhcp4o6-saddr-opt@ietf.org>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Eric Rescorla's Discuss on draft-ietf-dhc-dhcp4o6-saddr-opt-06: (with DISCUSS and COMMENT)

Thanks for your note

First, let me apologize: I somehow forgot to include that I think Ben's point is
correct: there seems to be an amplification attack in which I rebind my
IPv4 address to some victim's IPv6 address with the result that they
get a pile of traffic. Do you agree with that?

[if – I see what you mean. I think this can be cleared up with an additional
Check at the server:

8.2.  Handling Conflicts Between Client's Bound IPv6 Source Addresses

   In order for traffic to be forwarded correctly, each CE's softwire
   IPv6 source addresses must be unique.  To ensure this, on receipt of
   every client DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR,
   the DHCP 4o6 server MUST check the received IPv6 address against all
   existing CE source addresses stored for active client IPv4 leases.
   If there is a match, then the client's source address MUST NOT be
   stored or updated.

   Depending on where the client and server are in the address leasing
   lifecycle, the DHCP 4o6 server then takes the following action:

   o  If the DHCP 4o6 does not have a current, active IPv4 address lease
      for the client, then the DHCP address allocation process has not
      been successful.  The server returns a DHCPNAK message to the
      client.
   o  If the DHCP 4o6 does have a current, active IPv4 address lease,
      then the source address update process (see Section 8.1) has not
      been successful.  The DHCP 4o6 server can either silently drop the
      client's message or return a DHCPACK message containing the
      existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR.
]


On Fri, Oct 12, 2018 at 3:45 AM <ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>> wrote:


On 11.10.18, 04:13, "dhcwg on behalf of Eric Rescorla" <dhcwg-bounces@ietf.org<mailto:dhcwg-bounces@ietf.org> on behalf of ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:

    Eric Rescorla has entered the following ballot position for
    draft-ietf-dhc-dhcp4o6-saddr-opt-06: Discuss

    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)


    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp4o6-saddr-opt/



    ----------------------------------------------------------------------
    DISCUSS:
    ----------------------------------------------------------------------

    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.


      A rogue client could attempt to use the mechanism described
      in Section 4.2.1 to redirect IPv4 traffic
      intended for another client to itself. This would be performed by
      sending a DHCPREQUEST message for another client's active IPv4
      lease containing the attacker's softwire IPv6 address in
      OPTION_DHCP4O6_S46_SADDR.

      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. This could
      be attempted in three ways:

      1, One customer learning the active IPv4 address lease
         and client identifier of another customer via snooping
         the DHCP4o6 message flow between the client
         and server. The mechanism described in this document is
         intended for use in a typical ISP network topology with
         a dedicated layer-2 access network per-client,
         meaning that snooping of another client's traffic is
         not possible. If the access network is a shared
         medium then it provisioning softwire clients using
         dynamic DHCP4o6 as described here is
         not recommended.

You probably want to use NOT RECOMMENDED.

[if – OK]

      2, Learning the active IPv4 address lease and client identifier
         via snooping the DHCP4o6 message flow between the client
         and server in the aggregation or core ISP network.
         In this case, the attacker requires a level
         of access to the ISP's infrastructure that means they can already
         intercept or interfer with traffic flows to the client.

This is true, but generally we consider cheap traffic redirection attacks as
a problem

[if – Do you think that the changes I’ve proposed now address this?]


      3, An attacker could attempt to brute-force guessing the IPv4
         lease address and client identifier tuple. The risk of
         this can be reduced by using a client identifier format
         which is not easily guessable, e.g., by using a UUID
         based client identifier (see [I-D.ietf-dhc-rfc3315bis]
         Section 11.5).

Is that really the most unguessable? I would have thought the random
one was best....

[if – OK. What about the following:

3, An attacker could attempt to brute-force guessing the IPv4 lease
   address and client identifier tuple.  The risk of this can be
    reduced by using a client identifier format which is not easily
    guessable, e.g., by using a random based client identifier (see
    [RFC7844] Section 3.5).
]


    ]

    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    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.


[if - The abstract tries to cover this, but it could be made more clear. How
about:

OLD:
DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically
        configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6
NEW:
 DHCPv4 over DHCPv6 (RFC7341) is a mechanism for dynamically
        configuring IPv4 for use as an over-the-top service in a IPv6-only
        network. Softwires are an example of such a service. For DHCPv4 over
        DHCPv6.....

LGTM.

]

    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?

[if - DHCPOFFER contains an address proposal for the client, but the actual
allocation is not made until the client sends the DHCPREQUEST for the
address and the server responds with the DHCPACK saying that that the
allocation request has been successful.

Would it be helpful to add a pointer here to Section 3.1 "Client-server interaction
- allocating a network address" of RFC2131?]

Yes, but i think it would be best to annotate diagram with it.

-Ekr



    _______________________________________________
    dhcwg mailing list
    dhcwg@ietf.org<mailto:dhcwg@ietf.org>
    https://www.ietf.org/mailman/listinfo/dhcwg