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

From: "Guang Yao" <[email-masked]>
Date: Tue, 13 Dec 2011 01:52:44 +0800

Hi Jari,

Thank you very much for the review. Sorry for this late reply.

We have modified the document as the attachment. And I try to answer your
questions as follows inline. Looking forward to your reply.

Best regards,
Guang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jari
> Arkko
> Sent: Thursday, September 22, 2011 2:41 AM
> To: Jun Bi
> Cc: SAVI Mailing List
> Subject: [savi] AD review of draft-ietf-savi-dhcp-10
> 
> 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?
[Guang Yao] 

We do want to support l2 mobility in IPv4. However, we find it is hard to
distinguish an attack which uses reachability test to obtain binding
belonging to another host from a normal l 2 movement. The message received
by the SAVI device can be exactly the same.

We decide the handle only one scenario, as discussed in section 11:

"To be compatible with DNAv4 [RFC4436], after a binding anchor turns
off-link, if reachability test message specified in section 2.1.1 of
[RFC4436] is received from another binding anchor which turns on-link
afterwards, the binding MAY be migrated to the latter binding anchor. The
binding recovery procedure specified in section 8.1 MUST be performed to
ensure the binding migration is reasonable."

And the issue is discussed in section 13.6:

"DNA [RFC4436] [RFC6059] is designed to decrease the handover latency after
re-attachment to the same network. DNA mainly relies on sending unicast
Neighbor Solicitation/ARP message to detect whether a previously configured
address is still valid.
In Simple DNAv6 [RFC6059], the DHCP exchange step is required, thus it is
compatible with SAVI. However, in DNAv4 [RFC4436], the DHCP exchange
procedure in current standards is not mandatory. If a binding is set up only
through snooping the reachability test message, the binding can be invalid.
For example, an attacker can perform reachability test with address bound to
another host. If binding is migrated to the attacker, the attacker can
successful obtain the binding from the victim.
For security, in this mechanism, a binding can be migrated to a different
binding anchor only if the previous binding anchor is off-link and the new
binding anchor is on-link afterwards, as specified in section 11. If a
binding anchor is on-link, its bindings will never migrate to another
binding anchor.
If a DNAv4 node moves without triggering link-down/up event on SAVI device,
the binding will not migrate. In this case, the DNAv4 node MUST perform DHCP
exchange to recover binding after re-attachment. But binding can also be
recovered based on the binding recovery procedure specified in section 8.1,
if the SAVI-BindRecovery attribute is set on the new binding anchor."

Though making binding recovery process mandatory can help, it also brings
risks. Anyway, the address is not assigned by DHCP server to the host; in
fact, we just suppose the host is able to use the address because the
address has been assigned by the DHCP server to someone on the link and it
is not currently used by any other node.

IMHO, the savi mechanism for DHCP address must strictly follow the DHCP
exchange procedure. If binding is also set up based on snooping other
messages, the benefit and the risk must be trade-off carefully.

> 
> > 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.
> 
[Guang Yao] 
It's is a good idea to recovery lease time from bst if the host moves only
on the same SAVI device. We have changed the text:

"Because no lease time will be contained in the REPLY from DHCP server, the
SAVI device MUST lookup in BST to determine whether there is an entry with
the same address. If there is such an entry, it can be a local movement and
the lifetime can be recovered from the entry. If there is not, the SAVI
device MUST send a LEASEQUERY [RFC5007] message querying by IP address to
All_DHCP_Relay_Agents_and_Servers multicast address [RFC3315] or a
configured server address."

And we change the text in 7.4.2 correspondingly:
"If the Reply message is of Status Code Success, and there is an entry with
the same address, set the Lifetime to be the remaining Lifetime of the
existing entry, and remove the existing entry. If there is no entry with the
same address, set the Lifetime of corresponding entry to
MAX_LEASEQUERY_DELAY."

> >       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).
[Guang Yao] 

I don't think there is any implication for DNAv6. DNAv6 uses link local
address to send detection message. Link local address is not assigned by
DHCP and the corresponding binding and the implication should be specified
in other document (maybe the mix document).

> 
> >     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?
[Guang Yao] 

Previously we consider if the host is dis-connected for a certain time, its
interface will re-initialized. Thus there is no need to keep the binding
long.

If considering L2 mobility, the require time must be more than
T(movement)+T(interface initilization)+T(DHCP/DNA)

to keep the entry until the host finish address configuration.

We decide change it to 30 seconds.

> Editorial:
> 
> >                          Figure 2 Instance of BST
> 
> First use of the abbreviation BST. Please expand somewhere.
[Guang Yao] 
Done. in the title of the section.
> >                           Figure 3 Instance of FT
> As above.
[Guang Yao] 
Done. in the title of the section.
> 
> > If there is enough binding
> >       entry resource,
> 
> resources
[Guang Yao] 
Done
> 
> >       If the binding anchor is switch port, there can be vulnerability
> > in
> >
> 
> a switch port
[Guang Yao] 
Done.
> 
> Jari
> 
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi