[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
- [dhcwg] Eric Rescorla's Discuss on draft-ietf-dhc… Eric Rescorla
- Re: [dhcwg] Eric Rescorla's Discuss on draft-ietf… ian.farrer
- Re: [dhcwg] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla
- Re: [dhcwg] Eric Rescorla's Discuss on draft-ietf… ian.farrer
- [dhcwg] FW: Eric Rescorla's Discuss on draft-ietf… ian.farrer
- Re: [dhcwg] FW: Eric Rescorla's Discuss on draft-… Eric Rescorla
- Re: [dhcwg] Eric Rescorla's Discuss on draft-ietf… ian.farrer