Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-bulk-leasequery-00

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 19 May 2008 09:37:54 -0400

I fully support this work moving forward, but I believe we need to
address a bunch of issues (mostly editorial) and respin before sending
this work on to the IESG.

--> I do hope others will chime in before the END
--> OF THE LAST CALL, which concludes *TODAY* (at
--> 1700EDT on 05-19-2008). Otherwise, this draft
--> may fail to progress as there has been *NO*
--> support for it (at least posted to the DHC WG
--> mailing list)!!!

Here are my review comments:

- Abstract

I question whether this is an "extension to the Leasequery Protocol".
This is a new protocol and I think we should declare it as such.

- 1. Introduction

3rd paragraph:
   Server(s).  The individual query mechanism is only useable when the
   target binding is known to the requestor.  In the case of DHCPv6
                                           ^ (add text below)
   Prefix Delegation, the PD binding data may need to be known before

Consider adding "such as upon receipt of traffic"?

- 3. Protocol Overview

1st paragraph:
   Leasequery client has server IP address(es) available via
   configuration or some other means, and that it has unicast IP
   reachability to the server.  The client sends a LEASEQUERY message,
   containing a query-type and data about bindings it is interested in.

I suggest move the "The client sends" to the next pargraph (perhaps
adding "Once the connection has been established, the client sends..."
and adding to the end of this first 1st paragraph: "No relaying of bulk
leasequery is specified."
 
2nd paragraph:
   Each end of the TCP connection can be closed after all data has been
   sent.

As this text makes it appear that only a single query / response is
possible, how about changing this to "Additional queries may be
performed. Each end of the TCP connection can be closed after all data
has been sent."

4th paragraph:

Change "RFC5007" to a reference number ([6]).

- 4. Interaction Between UDP Leasequery and Bulk Leasequery

2nd paragraph:

Again, change "RFC5007" to reference number ([6]).

3rd paragraph:

Is it worth adding a reference [6] after the "NotAllowed" status 

Other issue:

Is it worth mentioning that only LEASEQUERY, LEASEQUERY-REPLY,
LEASEQUERY-DATA, and LEASEQUERY-DONE messages are allowed over the
connection. No other DHCPv6 messages (SOLICIT, ...) are allowed. This is
not an alternative DHCPv6 communication option for clients to obtain
leases.

- 5.2.2. LEASEQUERY-DONE

1st paragraph:

   of a stream of reply messages.  A single LEASEQUERY-DONE MUST BE sent
   after all replies to a successful Bulk Leasequery request that
                    ^ (add text below?)
   returned at least one binding.

Would it help to insert "(a successful LEASEQUERY-REPLY and zero or more
LEASEQUERY-DATA messages)"?

- 5.3.3. QUERY_BY_REMOTE_ID

1st paragraph:

Change "Relay-ID" option to "Relay Agent Remote-ID Option [5]". May also
be best to include reference to [5] in the QUERY_BY_REMOTE_ID definition
(last "paragraph").

- 5.4.1. Relay-ID Option

1st paragraph:

Best to add a reference to [1] for DUID?

- 5.5. Status Codes

   TODO: are any new status codes needed - to indicate a connection or
   resource problem e.g.?

This section is obviously incomplete. I think we should define one new
status code:

QueryTerminated (11) - Indicates that the server is unable to perform a
query or has prematurely terminated the query for some reason (which
should be communicated in the text message). This may be because the
server is short on resources or is being shut down. The requester may
retry the query at a later time (the requestor should wait at least a
short interval before retrying). Note that while a server may simply
prematurely close its end of the connection, it is preferrable that a
server send a LEASEQUERY-REPLY or LEASEQUERY-DONE with this status-code
to notify the requestor of the condition.

- 6.3. Processing Replies

Last paragraph:

   The LEASEQUERY-DONE message ends a successful Bulk Leasequery session
   that returned at least one binding.  A LEASEQUERY-REPLY without any

I think "session" should be "request" here. Session might confuse the
issue about when the TCP connection is closed.

- 6.4. Querying Multiple Servers

   A Bulk Leasequery client MAY be configured to attempt to connect to
   and query from multiple DHCPv6 servers in parallel.  The DHCPv6
             ^^^^ drop from
   Leasequery specification [6] includes a discussion about reconciling
   binding data received from multiple DHCPv6 servers.

- 6.5.  Multiple Queries to a Single Server

In this section, we need to be clear about how this works (we don't want
to the confusion that exists with multiple DNS queries over TCP
connections!). We need to be clear that *IF* a client sends another
LEASEQUERY message to the server before the first is done, the client
MUST be prepared for the responses from the server to be interleaved
(i.e., the client must use the XID to match up the responses with the
request). A server is not required to process more than a request at a
time from the connection, but if it chooses to do so, it will send back
replies for each active query interleaved over the TCP connection.

The main points here are:
- A client MAY send more than one request at a time. If the client is
not capable of dealing with interleaved responses from a server, the
client MUST NOT send more than one request at a time.
- A server MAY process more than one request at a time and is allowed to
interleave the responses if it does so.

I also wonder whether we should provide an example here (or perhaps in a
new 6.7 section)? Such as:

     Client                        Server
     ------                        ------
     LEASEQUERY xid 1 ----->
                                   LEASEQUERY-REPLY xid 1 (w/error)
     LEASEQUERY xid 2 ----->
                      <-----       LEASEQUERY-REPLY xid 2
                      <-----       LEASEQUERY-DATA xid 2
                      <-----       LEASEQUERY-DATA xid 2
                      <-----       LEASEQUERY-DONE xid 2
     LEASEQUERY xid 3 ----->
     LEASEQUERY xid 4 ----->
                      <-----       LEASEQUERY-REPLY xid 4
                      <-----       LEASEQUERY-DATA xid 4
                      <-----       LEASEQUERY-REPLY xid 3
                      <-----       LEASEQUERY-DATA xid 4
                      <-----       LEASEQUERY-DATA xid 3
                      <-----       LEASEQUERY-DONE xid 3
                      <-----       LEASEQUERY-DATA xid 4
                      <-----       LEASEQUERY-DONE xid 4

Note that a server that did not support multiple queries would have
responded as:

     LEASEQUERY xid 3 ----->
     LEASEQUERY xid 4 ----->
                      <-----       LEASEQUERY-REPLY xid 3
                      <-----       LEASEQUERY-DATA xid 3
                      <-----       LEASEQUERY-DONE xid 3
                      <-----       LEASEQUERY-REPLY xid 4
                      <-----       LEASEQUERY-DATA xid 4
                      <-----       LEASEQUERY-DATA xid 4
                      <-----       LEASEQUERY-DATA xid 4
                      <-----       LEASEQUERY-DONE xid 4

7.4. Closing Connections

Perhaps in the 2nd paragraph, we should reference the QueryTerminated
status added to 5.5.

9. IANA Considerations

Add QueryTerminated status code assignment.

BTW: For the Query (and status codes) should the draft provide numbers
of leave them unspecified for IANA to assign them? IANA was requested to
create a registry for these in RFC 5007 (3315 did the status codes), so
perhaps best IANA is left to do the assignment?

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ralph Droms (rdroms)
Sent: Monday, April 28, 2008 1:33 PM
To: DHC WG
Cc: Dhc Chairs
Subject: [dhcwg] dhc WG last call on
draft-ietf-dhc-dhcpv6-bulk-leasequery-00

This message announces a WG last call on "DHCPv6 Bulk Leasequery"
<draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt>.  The last call will  
conclude at
1700EDT on 05-19-2008.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

There was an issue raised during the discussion of this draft at the
dhc WG meeting during IETF-71 regarding the termination of the TCP
connection after a bulk leasequery transaction.  That issue should be
discussed during this last call, and the duration of the last call has
been extended to three weeks to allow for that discussion.

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been
extended with a Leasequery capability that allows a client to request
information about DHCPv6 bindings.  That mechanism is limited to
queries for individual bindings.  In some situations individual
binding queries may not be efficient, or even possible.
draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt specifies extensions to
the Leasequery protocol that add new query types and allow for bulk
transfer of DHCPv6 binding data.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-bulk-leasequer
y-00.txt

- John Brzozowski, Ralph Droms
   dhc WG chairs

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Bud Millwood <[email-masked]>
Date: Mon, 19 May 2008 17:53:10 +0200

I support this with Bernie's comments except maybe the one "No relaying of 
bulk leasequery is specified." What does that mean? That TCP cannot be 
relayed? Is this stating the obvious or did I miss something?

Also, I was just wondering: How likely is it that a second-hop relay would 
perform a query-by-relay-id? It seems implicitly allowed.

- Bud

-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 19 May 2008 13:58:43 -0400

>"No relaying of bulk leasequery is specified."

It means that we have place no requirement on Relay Agents also
listening on *TCP* port 547 to relay bulked leasequery to a server.

As the text in that section states, it is assumed that the Leasequery
client has unicast reachability to the server.

I just figured it was worth clarifying that relayed messages
(Relay-Forw) should never be sent over TCP and that Relay Agent are not
required to listen for these connections.

>perform a query-by-relay-id? It seems implicitly allowed.

That is correct that it is allowed. I don't see why we'd want to
prohibit this and we're still early in the DHCPv6 deployment stages it
isn't clear how many relay hops will be used. Also, I can think of
reasons why the first hop relay may not need any of this information and
a second (or later) relay may be the one that needs to recover the
leases and hence would be doing bulk LQs.

Note that the original Leasequery (RFC 5007) specified:

4.1.2.4.  Relay Data

   The Relay Data option is used only in a LEASEQUERY-REPLY message and
   provides the relay agent information used when the client last
   communicated with the server.

   The format of the Relay Data option is shown below:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     OPTION_LQ_RELAY_DATA      |         option-len            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                  peer-address (IPv6 address)                  |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                       DHCP-relay-message                      |
       .                                                               .
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         option-code      OPTION_LQ_RELAY_DATA (47)

         option-len       16 + length of DHCP-relay-message.

         peer-address     The address of the relay agent from which
                          the relayed message was received by the
                          server.

         DHCP-relay-message
                          The last complete relayed message, excluding
                          the client's message OPTION_RELAY_MSG,
                          received by the server.

So, a DHCPv6 server should be able to locate the relay-id from any of
the Relay-Forw messages as it should be saving this data in the first
place (at least if the server wants to offer the ability to return this
relay data).

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bud Millwood
Sent: Monday, May 19, 2008 11:53 AM
To: [email-masked]
Subject: Re: [dhcwg] dhc WG last call
ondraft-ietf-dhc-dhcpv6-bulk-leasequery-00

I support this with Bernie's comments except maybe the one "No relaying
of 
bulk leasequery is specified." What does that mean? That TCP cannot be 
relayed? Is this stating the obvious or did I miss something?

Also, I was just wondering: How likely is it that a second-hop relay
would 
perform a query-by-relay-id? It seems implicitly allowed.

- Bud

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 19 May 2008 14:36:35 -0400

I too fully support this work moving forward. Please accept my support
as an access concentrator representative on this one. 

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernie Volz (volz)
Sent: Monday, May 19, 2008 9:38 AM
To: Ralph Droms (rdroms); DHC WG
Cc: Dhc Chairs
Subject: Re: [dhcwg] dhc WG last call
ondraft-ietf-dhc-dhcpv6-bulk-leasequery-00

--> I do hope others will chime in before the END OF THE LAST CALL, 
--> which concludes *TODAY* (at 1700EDT on 05-19-2008). Otherwise, this 
--> draft may fail to progress as there has been *NO* support for it (at

--> least posted to the DHC WG mailing list)!!!

- Abstract

- 1. Introduction

3rd paragraph:

- 3. Protocol Overview

1st paragraph:

2nd paragraph:

4th paragraph:

2nd paragraph:

3rd paragraph:

Other issue:

- 5.2.2. LEASEQUERY-DONE

1st paragraph:

1st paragraph:

- 5.4.1. Relay-ID Option

1st paragraph:

- 5.5. Status Codes

Last paragraph:

     Client                        Server
     ------                        ------
     LEASEQUERY xid 1 ----->

     LEASEQUERY xid 3 ----->
     LEASEQUERY xid 4 ----->

7.4. Closing Connections

9. IANA Considerations

- Bernie 

-----Original Message-----

This message announces a WG last call on "DHCPv6 Bulk Leasequery"
<draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt>.  The last call will
conclude at 1700EDT on 05-19-2008.

acceptance during the WG last call, the document will not be advanced to
the IESG.

There was an issue raised during the discussion of this draft at the dhc
WG meeting during IETF-71 regarding the termination of the TCP
connection after a bulk leasequery transaction.  That issue should be
discussed during this last call, and the duration of the last call has
been extended to three weeks to allow for that discussion.

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been
extended with a Leasequery capability that allows a client to request
information about DHCPv6 bindings.  That mechanism is limited to queries
for individual bindings.  In some situations individual binding queries
may not be efficient, or even possible.
draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt specifies extensions to the
Leasequery protocol that add new query types and allow for bulk transfer
of DHCPv6 binding data.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-bulk-leasequer
y-00.txt

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 19 May 2008 15:43:36 -0400

Ralph,

I fully support this work moving forward.  That said, I think Bernie's
comments need attention and I largely agree with them.  

Regards -- Kim

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 19 May 2008 16:09:01 -0400

Here are some comments from me:

1. I think this protocol is an extension of DHCPv6 single LQ, so the
Abstract looks ok to me. I am not too strong if folks like Bernie deem
this a new protocol. I also agree in general with all of Bernie's
comments.

2. In particular, I totally agree with Bernie on replacing Relay-ID in
section 5.3.3 to Relay Agent Remote-ID Option. The Relay-ID short term
may mislead folks to thinking it's an entity related to relay whereas
the term is totally not. It's as simple as the cable modem mac-addr when
the cable modem is a DHCPv6 client that the relay agent is serving. A
cable modem is never verified using DHCP Lease Query (LQ) in a cable
deployment. Only the hosts behind the modem are verified via LQ. That is
why remote-id is such a key option for DHCP LQ because the relay needs
to know from server what modem is the host behind.

2. Section 7.1 in Server Behavior. I have a question related to
following text:

[Servers MAY restrict Bulk Leasequery connections and LEASEQUERY
   messages to certain clients.  Connections not from permitted clients
   SHOULD BE closed immediately, to avoid server connection resource
   exhaustion.]

How does server know who is not a permitted client? Either the
deployment may initiate authentication between server and relay and only
connections from an authenticated relay will be accepted by server. Or
does the deployment deem a relay client as allowed client if the server
received thousands of DHCPv6 client messages via the relay and the
clients completed DHCPv6 with the server. Or it's a configuration on the
server that configures a bunch of relay agents on the server?

Thanks.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Monday, May 19, 2008 2:37 PM
To: Bernie Volz (volz); Ralph Droms (rdroms); DHC WG
Cc: Dhc Chairs
Subject: Re: [dhcwg] dhc WG last
callondraft-ietf-dhc-dhcpv6-bulk-leasequery-00

Hemant

-----Original Message-----

- Abstract

- 1. Introduction

3rd paragraph:

- 3. Protocol Overview

1st paragraph:

2nd paragraph:

4th paragraph:

2nd paragraph:

3rd paragraph:

Other issue:

- 5.2.2. LEASEQUERY-DONE

1st paragraph:

1st paragraph:

- 5.4.1. Relay-ID Option

1st paragraph:

- 5.5. Status Codes

Last paragraph:

     Client                        Server
     ------                        ------
     LEASEQUERY xid 1 ----->

     LEASEQUERY xid 3 ----->
     LEASEQUERY xid 4 ----->

7.4. Closing Connections

9. IANA Considerations

- Bernie

---

From: Mark Stapp <[email-masked]>
Date: Mon, 19 May 2008 16:22:18 -0400

Thanks, Hemant. a couple of inline responses...

> Here are some comments from me:

[...]

> section 5.3.3 to Relay Agent Remote-ID Option. 

yes, that's just a typo - will fix it.

> server that configures a bunch of relay agents on the server?

most of the above are possible, I guess. the point of the text there 
just is to highlight one of the possible DOS attacks if the server is 
not careful about managing the TCP connections associated with the protocol.

Regards,
Mark

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 19 May 2008 16:24:06 -0400

Good point about the permitted clients. I had assumed this meant based
on the source address of the TCP connection, and if that is indeed the
case, perhaps best to clarify. I guess another alternative is to await
the first request and base this on the ClientID option presented therein
(for the requestor) and limit the message to a set of ClientIDs. Or,
both. It probably is up to an implementation to decide this?

Also, this does bring up an interesting question that somewhat also
relates to issue (1) below ... Nothing is stated in the draft as to
whether these TCP connections are over IPv6 or IPv4. Do we care? (For
some TCP/IP stacks, it actually requires two sockets to support both and
as this is about DHCP*v6* ... so these may be small arguments for
restricting this to IPv6.)

Further, looking back over the security considerations, I wonder whether
adding something about that LQ is primarily for use "inside" an
adminstrative domain and that border gateways should restrict TCP based
DHCPv6-port traffic (much like they normally would UDP based DHCPv6-port
traffic).

- Bernie

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Monday, May 19, 2008 4:09 PM
To: Hemant Singh (shemant); Bernie Volz (volz); Ralph Droms (rdroms);
DHC WG
Cc: Dhc Chairs
Subject: RE: [dhcwg] dhc WG last
callondraft-ietf-dhc-dhcpv6-bulk-leasequery-00

Thanks.

Hemant

-----Original Message-----

Hemant

-----Original Message-----

- Abstract

- 1. Introduction

3rd paragraph:

- 3. Protocol Overview

1st paragraph:

2nd paragraph:

4th paragraph:

2nd paragraph:

3rd paragraph:

Other issue:

- 5.2.2. LEASEQUERY-DONE

1st paragraph:

1st paragraph:

- 5.4.1. Relay-ID Option

1st paragraph:

- 5.5. Status Codes

Last paragraph:

     Client                        Server
     ------                        ------
     LEASEQUERY xid 1 ----->

     LEASEQUERY xid 3 ----->
     LEASEQUERY xid 4 ----->

7.4. Closing Connections

9. IANA Considerations

- Bernie

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 19 May 2008 16:28:19 -0400

Mark,

Thanks for the quick reply. I am fine with your resolutions below. 

I just wanted folks to be more aware of security with Bulk LQ vs. single
LQ because now a rogue can request a high volume of data with Bulk LQ
that Single LQ could not. There may be routers between the relay and the
server and those routers will now also be beleaguered with this high
volume of data. You see a rogue relay could masquerade as a legitimate
relay and then request a lot of data to choke the router in between but
when the data reaches the rouge relay, this relay does not process this
data but keeps the volume going.

Thanks.

Hemant

-----Original Message-----
From: Mark Stapp (mjs) 
Sent: Monday, May 19, 2008 4:22 PM
To: Hemant Singh (shemant)
Cc: DHC WG
Subject: Re: [dhcwg] dhc WG last

[...]

> deployment may initiate authentication between server and relay and 
> only connections from an authenticated relay will be accepted by 
> server. Or does the deployment deem a relay client as allowed client 
> if the server received thousands of DHCPv6 client messages via the 
> relay and the clients completed DHCPv6 with the server. Or it's a 
> configuration on the server that configures a bunch of relay agents on
the server?

most of the above are possible, I guess. the point of the text there
just is to highlight one of the possible DOS attacks if the server is
not careful about managing the TCP connections associated with the
protocol.

Regards,
Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 19 May 2008 16:34:36 -0400

Bernie,

In cable Service Provider (SP) deployment, the CMTS (Cable Modem
Termination System) which is also the relay may be in a hut somewhere in
the boonies whereas the server sits in an administrative domain of the
SP. The server is relatively secure, but the CMTS is not. Also, in such
a deployment there will likely be a router between the CMTS relay and
the server. I think now some interesting attacks can be initiated to the
server with Bulk LQ that were not possible with single LQ where the
attack may just bring the middle router (between relay and server) to
its knees. I am assuming the rogue LQ Requester convinced the server
it's a legitimate Requester and server starts sending volumes of data to
the Requester. 

Hemant

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Monday, May 19, 2008 4:24 PM
To: Hemant Singh (shemant); Ralph Droms (rdroms); 'DHC WG'
Cc: 'Dhc Chairs'
Subject: RE: [dhcwg] dhc WG last

- Bernie

-----Original Message-----
From: Hemant Singh (shemant)
Sent: Monday, May 19, 2008 4:09 PM
To: Hemant Singh (shemant); Bernie Volz (volz); Ralph Droms (rdroms);
DHC WG
Cc: Dhc Chairs

Thanks.

Hemant

-----Original Message-----

Hemant

-----Original Message-----

- Abstract

- 1. Introduction

3rd paragraph:

- 3. Protocol Overview

1st paragraph:

2nd paragraph:

4th paragraph:

2nd paragraph:

3rd paragraph:

Other issue:

- 5.2.2. LEASEQUERY-DONE

1st paragraph:

1st paragraph:

- 5.4.1. Relay-ID Option

1st paragraph:

- 5.5. Status Codes

Last paragraph:

     Client                        Server
     ------                        ------
     LEASEQUERY xid 1 ----->

     LEASEQUERY xid 3 ----->
     LEASEQUERY xid 4 ----->

7.4. Closing Connections

9. IANA Considerations

- Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 19 May 2008 16:51:59 -0400

If there isn't physical security there's probably a lot more that
someone can do?

But, this is also exactly my point about the changes to the security
considerations. There are two sides of the CMTS - the customer facing
side and the SP side. I would assume that we'd want the CMTS to have
filters against allowing DHCPv6 Bulk LQ requests from the customer
facing side of the CMTS (just as it restricts other customer traffic).
So, this would protect things well.

If someone can get into where the CMTS is, they likely could tap the SP
network connection going into the CMTS and do a lot more. So, if the SP
is concerned about this, they'd obviously want this network access to go
over a secured tunnel and then there's no issue as all network access
would be secured.

So, the Bulk LQ threat is really no different than the regular DHCPv6
threat.

And, while Bulk LQ could generate a lot of traffic (if for example we
allowed someone to request all bindings), but that's also a reason that
kind of query doesn't exist. I think the most that can be requested is
all of the bindings for a relay (assuming you know the relay-id). Yes,
this could still be a large number (several 100 thousand).

- Bernie

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Monday, May 19, 2008 4:35 PM
To: Bernie Volz (volz); Ralph Droms (rdroms); 'DHC WG'
Cc: 'Dhc Chairs'
Subject: RE: [dhcwg] dhc WG last

Bernie,

Hemant

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Monday, May 19, 2008 4:24 PM
To: Hemant Singh (shemant); Ralph Droms (rdroms); 'DHC WG'
Cc: 'Dhc Chairs'
Subject: RE: [dhcwg] dhc WG last

- Bernie

-----Original Message-----
From: Hemant Singh (shemant)
Sent: Monday, May 19, 2008 4:09 PM
To: Hemant Singh (shemant); Bernie Volz (volz); Ralph Droms (rdroms);
DHC WG
Cc: Dhc Chairs

Thanks.

Hemant

-----Original Message-----

Hemant

-----Original Message-----

- Abstract

- 1. Introduction

3rd paragraph:

- 3. Protocol Overview

1st paragraph:

2nd paragraph:

4th paragraph:

2nd paragraph:

3rd paragraph:

Other issue:

- 5.2.2. LEASEQUERY-DONE

1st paragraph:

1st paragraph:

- 5.4.1. Relay-ID Option

1st paragraph:

- 5.5. Status Codes

Last paragraph:

     Client                        Server
     ------                        ------
     LEASEQUERY xid 1 ----->

     LEASEQUERY xid 3 ----->
     LEASEQUERY xid 4 ----->

7.4. Closing Connections

9. IANA Considerations

- Bernie

---

From: Mark Stapp <[email-masked]>
Date: Fri, 23 May 2008 11:46:48 -0400

Hi Bernie,

thank you for all of the comments. I've published a new revision that 
incorporates pretty much all of them. I did have a couple of responses 
inline...

Bernie Volz (volz) wrote:
[...]

> This is a new protocol and I think we should declare it as such.

I guess I think it 'extends' RFC5007 because it uses the same messaging,
and the same new options. I've tweaked that text slightly, using 
"expands" instead - see what you think.

[...]

> to notify the requestor of the condition.

I have added this new status code, because there did seem to be at least 
of couple of others who supported the suggestion. But for my own part, I 
don't really buy it. from the client's end, the connection goes down, 
and it doesn't really matter "why". about the best the client can do is 
to try other servers, if possible, or wait until it can reconnect.

Thanks again,
Mark

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 23 May 2008 11:57:46 -0400

Great - I'll take a look over the next few [working] days.

Yes, the status code is of marginal value in terms of the actions that
the LQ client would take - it would need to retry in either case. But I
think it can make a difference in terms of debugging/logging/reporting.
If the connection just drops, that could mean any number of things and
doesn't help someone monitoring the LQ client to determine what is going
wrong. So, I think it has significant value in terms of being able to
understand why the connection did drop before the transaction completed.

The LQ client would be able to report two different errors:
- LQ connection to server ... was lost for an unknown reason.
- LQ connection to server ... was lost because server reported "<text
message>".

Think of it this way, programs could always just report "Sorry, a
failure has occurred" or they could tell you why there was a failure --
which would you prefer as a user?

- Bernie 

-----Original Message-----
From: Mark Stapp (mjs) 
Sent: Friday, May 23, 2008 11:47 AM
To: Bernie Volz (volz)
Cc: DHC WG
Subject: Re: [dhcwg] dhc WG last call on

Hi Bernie,

[...]

Thanks again,
Mark

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 28 May 2008 15:05:23 -0400

Mark:

The draft looks fine.

For some of the new text, not sure if should/SHOULD or may/MAY should
have been used (lower case was generally used) - such as in 5.5 (Status
Codes).

--

An item that I missed earlier ... for the QUERY_BY_RELAYID or
QUERY_BY_REMOTE_ID, I wonder whether it is necessary to indicate that
for multi-hop relayed client requests, the server SHOULD look through
the full chain of RELAY-FORW for a match (not just the "last" or "first"
hop).

--

I guess now a question to the DHC WG chairs ... What is the status of
this document? Is the last-call completed and did it "pass"? Will it go
to the IESG or is there more to be done on it before it can move
forward?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernie Volz (volz)
Sent: Friday, May 23, 2008 11:58 AM
To: Mark Stapp (mjs)
Cc: DHC WG
Subject: Re: [dhcwg] dhc WG last call
ondraft-ietf-dhc-dhcpv6-bulk-leasequery-00

- Bernie 

-----Original Message-----
From: Mark Stapp (mjs) 
Sent: Friday, May 23, 2008 11:47 AM
To: Bernie Volz (volz)
Cc: DHC WG
Subject: Re: [dhcwg] dhc WG last call on

Hi Bernie,

[...]

Thanks again,
Mark