Subject: [savi] AD review of draft-ietf-savi-dhcp-10

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Sep 2011 21:40:52 +0300

I have reviewed this draft. I have to apologize that it has taken so long, and I know you are waiting for me on a number of other open issues in the working group. I've been more busy than usual with day job, as well as having many documents in my review queue.

The draft is in pretty good shape, but there are a couple of issues that we still need to work on.

Technical:

We need to have the DHC WG folks review this in detail. I am not expert enough in verifying that everything is correct, and while we've had some DHCP folk participate the work, I think more review would be useful. This is a general principle in fact with all DHCP-related work in the IETF: we often like to run parallel working group last calls in the home working group of a draft as well as in DHC WG. I have asked for this review to be started now.

I do not understand how the draft works with DNAv4 (RFC 4436) and the DHCP rebinding procedure. The draft seems to be saying that it does not support L2 mobility (either through something like radio moving to a different AP on a WLAN) or through physical re-attachment on a different port. I think that it is such a basic requirement that we need to support that.

Couldn't the SAVI device follow the new messages on the DHCP as well as the ARP messages from RFC 4436?

Would making Section 8 process mandatory to implement help?

> Because
> no lease time will be contained in the REPLY from DHCP server, the
> SAVI device MUST send a LEASEQUERY [RFC5007  <http://tools.ietf.org/html/rfc5007>] message querying by IP
> address to All_DHCP_Relay_Agents_and_Servers multicast address
> [RFC3315  <http://tools.ietf.org/html/rfc3315>] or a configured server address.

This seems problematic. Can't the lease time be recovered from earlier messages and stored in the SAVI data structures? Note that RFC 5007 requires typically special security solutions (e.g., IPsec) and sets high requirements on what the SAVI device must do with the DHCP server.

>       Discard IPv6 Neighbor Solicitation (NS) and IPv4 gratuitous ARP
>       whose source is not an address bound with the corresponding binding
>       anchor.

Please document if this has any implications for DNAv6 (RFC 6059).

>     Whenever a binding anchor with attribute SAVI-Validation turns down,
>     set a timer with OFFLINK_DELAY. Until the timer becomes zero, the
>     bindings with the binding anchor SHOULD be kept. As an exception, to
>     handle movement, if receiving DAD Neighbor Solicitation/Gratuitous
>     ARP request targeting at the address during OFFLINK_DELAY, the entry
>     MAY be removed.
>
>     ...
>
>     OFFLINK_DELAY              2s

This seems awfully short time, what is the number based on? Do we know what computers that go to short suspend state do when they wake up? Do they re-DHCP, use DNAv4/6, or just continue if the period was short enough?

Editorial:

>                          Figure 2 Instance of BST

First use of the abbreviation BST. Please expand somewhere.

>                           Figure 3 Instance of FT

As above.

> If there is enough binding
>       entry resource,

resources

>       If the binding anchor is switch port, there can be vulnerability in
>

a switch port

Jari