Re: [dhcwg] Alissa Cooper's No Objection on draft-ietf-dhc-rfc3315bis-10: (with COMMENT)

Tomek Mrugalski <> Thu, 25 January 2018 03:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 291CD12D7EC; Wed, 24 Jan 2018 19:16:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fOUb6vnEA5zy; Wed, 24 Jan 2018 19:16:04 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC5161289B0; Wed, 24 Jan 2018 19:16:03 -0800 (PST)
Received: by with SMTP id q194so7888884lfe.13; Wed, 24 Jan 2018 19:16:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9HpWEMMWlI7PknGv9xCiYhlsXYWa8KJ6xUxZzov3gjY=; b=Yc1BTSlCVut641LYx1Chck8Qu+FPwW/Uyd9KKGINmkIx+HcxQR8y+jVqmMMeZdAJkg Y6WaQ5xhMD4mom+JBAIf3F3qVXrR024675GJ7iaq9ntMrbVco8mwc2dargg0GCkfH7+E tsw+ymzdo0vKks9sWO1RiBGxrgAqLwaYB/3DLFeEM7RVddiTzaWAZdFJopgzZD+LDYp3 5otLIwkSQH4tcek1WblgadPSm+YVDpuJbJ/ypAR4BSu8ytTO0O2AsJfTc1V8IMAC/igu sIVMhkZrDl6NuulFIFCZC+B2G8JE+ya3ET7mCC2SaAQyvql7q6UCh/oigGUi0SGRCpqK aIcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9HpWEMMWlI7PknGv9xCiYhlsXYWa8KJ6xUxZzov3gjY=; b=LdHxqlYAFEtTo25LVa73kGI7qe24VEKlafRzitrHi1U8KpCwt1T9e9X0qcxbduut8j rnXtjppqPG02jCF7HhlT23ltQ6XZjr7ZAlGvZfbQ/JpMrZhzVlwPeoMn+RGy4wcdDiRI F8QJd3UR+jrVDr6EatqyN0OKV94cUtRz6UY3BAcULZTaoCKSeu5I6H642k9xvIi70iIh oZPzTQRvZ4VpzNBAa3Exo97gomVXbzrWKcttSOm+tZ9M3fWxnAVVzfeZPX6oKVOZJTcO 5X2+NeoUbPvPnZJy7MWEQFX1oLAeZa2icNeiv9PZRxSGDKtHD1bMz6df7lFhX6DTWH/c voTg==
X-Gm-Message-State: AKwxytdwzyo7JTMUEkGVzJQ2LN1V0eVAjgJhwnk3frUfBch/kd6rvtQT 6juubvaaki2jNuRxf73HwUc79bde
X-Google-Smtp-Source: AH8x225zS9dVK9gneU9FuMOh3x/rXLOhVofpi+/IzMtL9/q9dwBpm8oKB6769+JMa/sxG+DGE8ggqA==
X-Received: by with SMTP id x11mr5088644ljc.99.1516850161517; Wed, 24 Jan 2018 19:16:01 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id d8sm306436lja.54.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 19:16:00 -0800 (PST)
To: Alissa Cooper <>, The IESG <>
Cc:, Ralph Droms <>,,
References: <>
From: Tomek Mrugalski <>
Message-ID: <>
Date: Thu, 25 Jan 2018 04:15:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [dhcwg] Alissa Cooper's No Objection on draft-ietf-dhc-rfc3315bis-10: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Jan 2018 03:16:06 -0000

On 01/23/18 16:56, Alissa Cooper wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-dhc-rfc3315bis-10: No Objection

Thank you for your review and your favourable ballot. See my comments below.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Many thanks to the Gen-ART reviewer for a thorough review. It sounds like the
> authors plan to incorporate edits in response but I wanted to particularly call
> out these bits from his summary with which I agree:
> "I also found that the new document did not do a good job on the interactions
> between relay-agents and servers.  Particularly on the processing of options
> between relays and servers and details of reception of Relay-forward messages a
> little more detail would help naive readers.
Understood. How about adding a new Section 19.4 "Interaction between
relay agents and servers" with the following text. The text is a bit
long, but I believe it covers the topic adequately without going into
too much detail and should be easy enough to follow even by naive readers.

Each time a packet is relayed by a Relay Agent towards a server, a new
encapsulation level is added around the packet. Each relay is allowed to
insert additional options on the encapsulation level it added. If there
are multiple relays between a client and a server, multiple
encapsulations are used. Although it makes packet processing
slightly more complex, it has a big advantage of having clear indication
which relay inserted a given option. The response packet is expected to
travel through the same relays, but in reverse order. Each time a
response packet is relayed, one encapsulation level is removed.

In certain cases relays insert additional options. These options can be
inserted for several reasons. First, relays can insert additional
information about the client or how it is connected. That is usually
more trusted by a server administrator as it comes from a network
infrastructure rather then the client himself and cannot be easily
spoofed. These options can be used by the server to determine its
allocation policy.

Second, relay may need some information to send a response back to the
client. Relay agents are expected to be stateless (not retain any state
after a packet has been processed). Relay agent may include an option,
send it to the server and ask the server to echo the option back in the
response. This option will be then used by the relay agent to send the
response back. The client will never see this option. See RFC4994 for

Third, sometimes a relay is the best device to provide values for
certain options. A relay can insert an option to the client packet being
forward and ask the server to pass that option back to the client. The
client will receive that option. See RFC6422 for details.

Servers may want to retain the relay information after the packet
processing is completed for various reasons. One is a bulk leasequery
mechanism that may ask for all addresses and/or prefixes that were
assigned via specific relay. Second reason is reconfigure mechanism. The
server may chose to not send the Reconfigure message directly to the
client, but rather send it via relays. This particular behavior is
considered an implementation details and is out of scope for this document.

> Finally the draft has not made much of an effort to
> support possible alternative security algorithms - IETF policy now encourages
> protocols to deal with algorithm flexibility  - DHCPv6 as it stands is pretty
> thoroughly wedded to HMAC-MD5 and would need some (relatively small) IANA
> improvements plus some thought to cope with different algorithms."
Although getting an algorithm flexibility would be nice, it was never
the goal of this work. Our understanding was that publishing 3315bis
intends to provide cleaner, easier to read somewhat unified text, but
not introduce any new features. If we added this new feature, we'd soon
be dealing with a flood of new proposals.

It is worth mentioning that our hope was the draft-ietf-dhc-sedhcpv6
draft would move forward and solve algorithm flexibility (among many
other security issues), but sadly our hopes were proven futile. The WG
ran out of steam, is no longer able to move forward and the draft is
pretty much dead.

Thanks again for your review,