Subject: [mif] FW: New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Oct 2012 12:32:20 +0000

This draft proposes new DHCPv6 options to be added by the DHCPv6 relay agent when it generates a Relay-Forwarded message to influence the DHCPv6 server's response that modify the host's address policy table [I-D.ietf-6man-addr-select-opt] based on observed network characteristics. These options can also be used to conditionally disable IPv6 temporary addresses in a managed network for selective hosts without authentication supplicant.

Comments and suggestions are welcome.

--Tiru.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 15, 2012 11:41 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Prashanth Patil (praspati); Dan Wing (dwing)
Subject: New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt

A new version of I-D, draft-reddy-mif-dhcpv6-precedence-ops-02.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Filename:	 draft-reddy-mif-dhcpv6-precedence-ops
Revision:	 02
Title:		 Relay-Supplied DHCPv6 Precedence Options
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 11
URL:             http://www.ietf.org/internet-drafts/draft-reddy-mif-dhcpv6-precedence-ops-02.txt
Status:          http://datatracker.ietf.org/doc/draft-reddy-mif-dhcpv6-precedence-ops
Htmlized:        http://tools.ietf.org/html/draft-reddy-mif-dhcpv6-precedence-ops-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-reddy-mif-dhcpv6-precedence-ops-02

Abstract:
   Network configuration of hosts is currently relatively static with
   little consideration of dynamic network characteristics.  The network
   infrastructure is aware of dynamic network characteristics.  This
   specification extends DHCPv6 so that the DHCPv6 relay agent can
   influence a host's configuration.

The IETF Secretariat

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Oct 2012 12:41:24 +0000

On Oct 18, 2012, at 8:32 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> These options can also be used to conditionally disable IPv6 temporary addresses in a managed network for selective hosts without authentication supplicant.

How would that work?   Have you raised this in 6man?

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 20 Oct 2012 03:03:31 +0000

> From: Ted Lemon [mailto:[email-masked]]

> Sent: Thursday, October 18, 2012 6:11 PM

> Cc: [email-masked]

> Subject: Re: [mif] New Version Notification for draft-reddy-mif-dhcpv6-

> precedence-ops-02.txt

> On Oct 18, 2012, at 8:32 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>

> wrote:

> > These options can also be used to conditionally disable IPv6 temporary

> addresses in a managed network for selective hosts without authentication

> supplicant.

> How would that work?

Hi Ted,

For e.g. In Enterprise premises hosts with EAP kind of supplicants can be tracked even when the IP address changes but for guests, BYOD (Bring your Own Device) without such supplicants IP address based authentication is still required for such users. When Address-based authentication is used, re-

authentication occurs for each new address obtained by the host, which can create a lot of authentication transactions. Switches acting as DHCP relay agent can influence the DHCP server not to assign temporary addresses. It's explained in detail in section 3.2.1 "Avoiding Excessive IP-Based Authentication" of this draft.

> Have you raised this in 6man ?

The above point was discussed in 6man specific to privacy addresses http://www.ietf.org/mail-archive/web/ipv6/current/msg15710.html

--Tiru.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 20 Oct 2012 04:11:37 +0000

On Oct 19, 2012, at 11:03 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> Switches acting as DHCP relay agent can influence the DHCP server not to assign temporary addresses. 

Okay, so this is preventing DHCP assignment of IA_TA, not assignment of temporary addresses in general.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 21 Oct 2012 02:55:03 +0000

> Sent: Saturday, October 20, 2012 9:42 AM

Hi Ted,

Yes. In such Managed Networks, SLAAC is disabled and IPv6 addresses are only assigned using DHCPv6 server. Switches in such environments provide First Hop Security by gleaning DHCP/NDP messages and can make sure hosts are using the IPv6 addresses assigned by the DHCPv6 server only (Source Guard). With the technique in this draft only certain hosts will be permitted assignment of IA_TA and not for other hosts. 

--Tiru.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 21 Oct 2012 03:01:08 +0000

> Yes. In such Managed Networks, SLAAC is disabled and IPv6 addresses are only assigned using DHCPv6 server. Switches in such environments provide First Hop Security by gleaning DHCP/NDP messages and…

That makes sense—thanks for clarifying!

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Oct 2012 10:24:50 +0100

> That makes sense—thanks for clarifying!

It makes sense, but the draft doesn't explain that it is only
intended for use in managed networks where the suppression of
privacy is considered acceptable. I think this needs to be stated
in the Introduction, and the issue of (loss of) privacy needs to
be discussed in the Security Considerations.

How will users know that temporary addressing has been disabled?

Is there a risk of a rogue DHCPv6 relay switching off temporary
addressing for hosts that really need it?

Also, in the section

> 3.2.1.  Avoiding Excessive IP-Based Authentication

it says:

>                      When Address-based authentication is used, re-
>    authentication occurs for each address obtained by the host, which
>    can create a lot of authentication transactions.  To reduce this
>    chatter,

This doesn't convince me that the proposed feature is solving a real
problem. "A lot of" and "chatter" are vague terms. Can you add something
to suggest what size of a network would have a real performance problem
as a result?

Regards
   Brian Carpenter

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Oct 2012 15:52:25 +0000

> be discussed in the Security Considerations.

It might be worth mentioning in the security considerations section, but it's worth noting that this option increases the user's privacy, rather than decreasing it; users who are known to the local network get temporary addresses; only those users who haven't yet registered do not.

This would only occur on a network with a security policy that forbade privacy addresses in general.   It's already possible to do that with existing DHCP servers, routers and DHCP clients.

The incremental additional privacy may seem trivial, since the user is still being tracked by the local service provider whether they get privacy addresses or not on this network.   However, the user would at least in principle have real and meaningful privacy from being tracked by their IP address by service providers outside the administrative domain of the local network.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Oct 2012 11:53:40 +0900

On Thu, Oct 18, 2012 at 9:32 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> This draft proposes new DHCPv6 options to be added by the DHCPv6 relay
> agent when it generates a Relay-Forwarded message to influence the DHCPv6
> server's response that modify the host's address policy table
> [I-D.ietf-6man-addr-select-opt] based on observed network characteristics.

A few general points:

1. The draft deals with two DHCPv6 options, with different use cases. Why
are you combine the options? I believe things would be much clearer if each
option had its own draft with its own use case.

2. Why is this draft in MIF? The address selection option has nothing to do
with multiple interfaces, and is already being discussed in 6man. The
relay-supplied prefix option also has nothing to do with multiple
interfaces.

3. The introduction does not provide a problem statement that matches the
solutions. The introduction says that "DHCPv6 allows relatively static
information to be configured in hosts, which is somewhat limiting", but
then states that the problem can be fixed by introducing DHCPv6 options. I
don't see how this is possible. DHCPv6 options cannot make things more
dynamic, since in DHCPv6, options are only handed out at request/response
time, and DHCPv6 options cannot change how often requests are made. Since
the options being proposed as solutions do not solve the problem, the draft
needs another problem statement.

4. The draft confuses RFC4941 privacy addresses with IA_TA options.
Ignoring IA_TA options will not disable RFC4941 privacy addresses, because
they are only used by SLAAC. The references to RFC 4941 should be removed.

As regards the address selection option specifically:

1. The option itself is still work in progress in 6man. So the
modifications should happen in 6man, not here. Otherwise we will have two
working groups working on the same option which is likely to have bad
results.
3. I don't understand the use case (Section 3.1). If the DHCPv6 relay is in
the mobile access gateway, then it's in the mobile operator's network. If
it's in the mobile operator's network, then how can it "influence the
DHCPv6 Server in the home network"? In general, the DHCPv6 server in the
home network has no way of talking to the mobile operator's network.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 24 Oct 2012 17:42:14 +0000

Hi Brian,

On 23/10/12 2:54 PM, "Brian E Carpenter" <[email-masked]>
wrote:

>>> Yes. In such Managed Networks, SLAAC is disabled and IPv6 addresses
>>>are only assigned using DHCPv6 server. Switches in such environments
>>>provide First Hop Security by gleaning DHCP/NDP messages and can make
>>>sure hosts are using the IPv6 addresses assigned by the DHCPv6 server
>>>only (Source Guard). With the technique in this draft only certain
>>>hosts will be permitted assignment of IA_TA and not for other hosts.
>> 
>> That makes sense‹thanks for clarifying!
>

Sure, will state as suggested.

>How will users know that temporary addressing has been disabled?

Users wont. I suppose guests authenticating using Webauth could be served a
disclaimer page that points this out. It's the administrative domain that
makes this decision.

>addressing for hosts that really need it?

DHCP authentication should be used to counter such risks. A DHCP server
would then only process relay options included by a valid relay agent.

>to suggest what size of a network would have a real performance problem

When IP address based authentication eg Webauth is used, the
authentication device will end up authenticating each and every temporary
address used by the client - So 'a lot of' here implies that the number of
authentications is equal to the number of temporary addresses used by the
host - this would also lead to bad user experience. The same number of
transactions with the backend AAA server to validate user credentials will
also have to be made.
Will add these details.

-Prashanth

>
>Regards
>   Brian Carpenter
>
>
>_______________________________________________
>mif mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mif

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 25 Oct 2012 05:57:54 +0000

Please see inline [Tiru]

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Wednesday, October 24, 2012 8:24 AM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [mif] FW: New Version Notification for draft-reddy-mif-dhcpv6-precedence-ops-02.txt

On Thu, Oct 18, 2012 at 9:32 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
This draft proposes new DHCPv6 options to be added by the DHCPv6 relay agent when it generates a Relay-Forwarded message to influence the DHCPv6 server's response that modify the host's address policy table [I-D.ietf-6man-addr-select-opt] based on observed network characteristics. These options can also be used to conditionally disable IPv6 temporary addresses in a managed network for selective hosts without authentication supplicant.

A few general points:

1. The draft deals with two DHCPv6 options, with different use cases. Why are you combine the options? I believe things would be much clearer if each option had its own draft with its own use case.
[Tiru] Sure, we will create two different drafts. After we split the draft into two [1] we will post Absolute Precedence Option with relevant use cases in 6man [2] Relay-supplied prefix option in DHCP WG.

2. Why is this draft in MIF? The address selection option has nothing to do with multiple interfaces, and is already being discussed in 6man. The relay-supplied prefix option also has nothing to do with multiple interfaces.
[Tiru] Yes. Only Absolute Precedence Option deals with MIF scenario where Mobile Node is assigned prefixes from both Local Access Network and Home Network. We had other multi-homing use cases in 01 version which are removed in 02.

3. The introduction does not provide a problem statement that matches the solutions. The introduction says that "DHCPv6 allows relatively static information to be configured in hosts, which is somewhat limiting", but then states that the problem can be fixed by introducing DHCPv6 options. I don't see how this is possible. DHCPv6 options cannot make things more dynamic, since in DHCPv6, options are only handed out at request/response time, and DHCPv6 options cannot change how often requests are made. Since the options being proposed as solutions do not solve the problem, the draft needs another problem statement.
[Tiru] Agreed the problem statement needs to be fixed in this version.

But we are evaluating other scenarios for the next version  For e.g. In IPv6 multi-homing, dual stack scenarios - where Relay agent dynamically influences the host policy table If IPv6 connectivity is detected to be broken (Section 10.3.1 of RFC 6724). This can be achieved by Relay Agent sending RECONFIGURE-REQUEST (http://tools.ietf.org/html/draft-ietf-dhc-triggered-reconfigure-01) to the DHCPv6 server providing the updated policy table in Absolute Precedence Option. DHCPv6 server will in turn initiate reconfigure message with the client, resulting in the client to initiate Renew/Reply or information-request/Reply transaction with the server to receive updated Policy Table OR

Do you think we can send the dynamic policy table in RA itself and solve the problem (but then it brings in complexity on the host if it is receiving policy table from two different sources)

Please let us know your opinion before we proceed on this path .

4. The draft confuses RFC4941 privacy addresses with IA_TA options. Ignoring IA_TA options will not disable RFC4941 privacy addresses, because they are only used by SLAAC. The references to RFC 4941 should be removed.
[Tiru] Yes, will remove this part.

1. The option itself is still work in progress in 6man. So the modifications should happen in 6man, not here. Otherwise we will have two working groups working on the same option which is likely to have bad results.
[Tiru] Agreed

3. I don't understand the use case (Section 3.1). If the DHCPv6 relay is in the mobile access gateway, then it's in the mobile operator's network. If it's in the mobile operator's network, then how can it "influence the DHCPv6 Server in the home network"? In general, the DHCPv6 server in the home network has no way of talking to the mobile operator's network.

[Tiru] This use case is specific to Proxy Mobile IPv6 (RFC 5213). Where there is tie-up b/w the Local Access Network and Mobile Network. Mobile. MAG in the Local Access Network establishes tunnel with LMA in the Home network. MAG can act as a DHCP relay agent and can communicate with the DHCP server in the home network.

  MN   MAG(DHCP-R) LMA   DHCP-S

   |       |------->|      | 1. Proxy Binding Update *

   |       |<-------|      | 2. Proxy Binding Acknowledgement

   |       |========|      | 3. Tunnel/Route Setup*

   |------>|-------------->| 4. Solicit via DHCP-R

   |<------|<--------------| 5. Advertise via DHCP-R

   |------>|-------------->| 6. Request via DHCP-R

   |<------|<--------------| 7. Reply via DHCP-R

   |       |               |
We will add more details to explain these details in next version.

--Tiru.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 25 Oct 2012 19:26:53 +0900

Hi,

2012/10/24 Lorenzo Colitti <[email-masked]>:

> 1. The option itself is still work in progress in 6man. So the modifications
> should happen in 6man, not here. Otherwise we will have two working groups
> working on the same option which is likely to have bad results.
> it's in the mobile operator's network, then how can it "influence the DHCPv6
> Server in the home network"? In general, the DHCPv6 server in the home
> network has no way of talking to the mobile operator's network.

It looks to me this is not the modifications to the address selection option
happening in 6man, but it is another proposal for tweaking DHCPv6 messages
from clients at DHCP relay agent.

So, in other words, this option just depends on the address selection option.
If it is true, a work that depends on another work can be done separately in
a separate wg.

I do not know whether mif is the right place for this proposal, but generally
speaking it is the right place where the scope and motivation matche best.

Thanks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Oct 2012 10:09:07 +0900

> If it is true, a work that depends on another work can be done separately

Sounds reasonable.

> I do not know whether mif is the right place for this proposal, but
> generally speaking it is the right place where the scope and motivation
> matche best.
>

I disagree that MIF is the right place. MIF is chartered to deal with
multiple interfaces. "Allowing relay agents to modify DHCPv6 requests in
flight" and "allowing relay agents to initiate DHCPv6 requests on behalf of
clients" has nothing to do with multiple interfaces.