Subject: [savi] Comments on draft-ietf-savi-dhcp-01

From: Dong Zhang <[email-masked]>
Date: Thu, 15 Apr 2010 10:52:24 +0800

Hi,

I read the draft-ietf-savi-dhcp-01. And I have some comments.

In section 1,
>The binding process is inspired by the work of IP Source Guard.
For IP Source Guard, it needs a reference I suoppose.

In section 4,
>Considering not all the operating systems support [RFC5227], this solution is
>designed to be compatible with operating systems not complying with [RFC5227].
Does it mean the OSs which support rfc5227 will have a different procedure for 
this savi-dhcp solution? If so, pointing out the differences obviously, maybe 
in a separate section, will be more clear at least for me.

In section 6, 
>Entries are keyed on the anchor and source IP address. 
I do not understand why using the anchor and source IP address together as the 
key value. My understanding is when savi device receives a packet, it will use
the source IP as the index to look for the responding entry. After finding the 
right entry, it could check the anchor and the state. Since the mapping for 
the IP address to the anchor is 1:1 (while the mapping for the anchor to IP 
address may be 1:N), so only useing the source IP as the key is enough. Is that 
ture? If it is, the IP address should be put into the first column in the BST and 
the FT.

In section 11.1.1.3,
>The TID is kept for assurance that the assigned address can be bound with anchor 
>securely.
What does it mean *securely*? 
Transaction ID is used to associate messages and responses. 

In section 11.1.2.3,
>   assigned address is not bound with another anchor in current BST. If
>   the address has been bound with another anchor in current BST, the
>   SAVI device MUST check if the node associated with that anchor is
>   off-line. If yes, bind the address with the new entry and delete the
>   original binding; if no, keep the original entry and delete the new
>   entry in BST.
Generally, check should happen before create a new entry. While creating a new
entry first before checking whether the binding has already existed is not a 
conventional behavior. I guess, the START state could be combined with LIVE state 
perhaps. Thus, the state machine is a little bit simple.

In section 15,
>   Whenever an anchor with attribute SAVI-Validation turns down, the
>   bindings with the anchor MUST be kept for a short time.
A short time may be more obscure. Is it a concrete value for recommendation?

In section 17,
>   However, this feature may allow an attacker to send quantities of
>   packets with source addresses already assigned to other nodes. A
>   practical solution for this vulnerability is configuring the address
>   pool and allocation algorithm of the DHCP server carefully.
By controling the behavior of DHCP server could prevent the attacker to send 
packets with spoofed source address? I am not quite sure. Could you please 
explain it?

Thank you very much.

2010-04-15 
   
Dong Zhang
Huawei Symantec Technologies Co., Ltd
TEL：86-10-62721287
FAX：86-10-62721347
ADDRESS：3rd Floor,Section D, Keshi Building, No.28, Xinxi Rd., Shangdi, Haidian Dist., Beijing, China. 100085 

***********************************************************************************
This email and its attachments contain confidential information from HUAWEI SYMANTEC, which is intended only for the person or 
entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total 
or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you 
receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
**********************************************************************************

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 15 Apr 2010 15:39:27 +0800

Hi, Dong

Thanks for your comments. Corresponding clarifications will be made in the
next edition.

I will try to answer some of the questions.

> ture? If it is, the IP address should be put into the first column in the
BST and

One problem is, if the address has not been assigned, the anchor is needed
to search. For example, a request is sent, but reply has not been received.

> packets with spoofed source address? I am not quite sure. Could you please

This problem is stated in consideration that DHCP servers may assign the
same address to different nodes, or assign an address configured by other
mechanisms, e.g., slaac, static configuration. And DAD detection may not be
helpful because it is unreliable. This may allow the node to use a duplicate
address and may be exploited by attackers. The best solution is configure
DHCP address pool to avoid this vulnerability.

BR,
Guang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dong
> Zhang
> Sent: Thursday, April 15, 2010 10:52 AM
> To: savi
> Subject: [savi] Comments on draft-ietf-savi-dhcp-01
> 
> Hi,
> 
> conventional behavior. I guess, the START state could be combined with
LIVE
> state
> ADDRESS：3rd Floor,Section D, Keshi Building, No.28, Xinxi Rd., Shangdi,
Haidian
> Dist., Beijing, China. 100085
> 
> This email and its attachments contain confidential information from
HUAWEI
> SYMANTEC, which is intended only for the person or
> entity whose address is listed above. Any use of the information contained
> herein in any way (including, but not limited to, total
> or partial disclosure, reproduction, or dissemination) by persons other
than the
> intended recipient(s) is prohibited. If you
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi

---

From: Dong Zhang <[email-masked]>
Date: Mon, 19 Apr 2010 11:28:58 +0800

Hi,

>to search. For example, a request is sent, but reply has not been received.
I have found this problem. So I mentioned in my another comment,which said the 
START state could be combined with LIVE state perhaps. Imho, the binding 
procedure can start when receiving a DHCPv4 DHCPACK or DHCPv6 REPLY message. 
Then, create the BST or FT. Thus, the IP address is able to be filled into the 
table as the key value. 

>> perhaps. Thus, the state machine is a little bit simple.

Thanks.
------------------				 
Dong Zhang

2010-04-19

---

From: "Guang Yao" <[email-masked]>
Date: Mon, 26 Apr 2010 16:35:07 +0800

Hi, Dong

Sorry for late reply.

In the new edition, a new binding can be triggered on reply (but not
suggested).

The reason is the binding procedure triggered by reply may not be secure.
The mapping from link layer address to anchor on savi device may be
attacked(typically, the port-mac mapping can be flooded.). Thus we suggest
if reply is used to trigger binding, supplemental mechanism should be used
to ensure the security of the mapping. This point is discussed in the draft.
Actually, it was also discussed on the mailing list previously.

BR,
Guang

Dong
> Zhang
> Sent: Monday, April 19, 2010 11:29 AM
> To: Guang Yao
> Cc: [email-masked]
> Subject: Re: [savi] Comments on draft-ietf-savi-dhcp-01
> 
> Hi,
> 
> >> I do not understand why using the anchor and source IP address together
as
> >> the
> >> key value. My understanding is when savi device receives a packet, it
will
> >use
> >> the source IP as the index to look for the responding entry. After
finding
> >the
> >> the IP address to the anchor is 1:1 (while the mapping for the anchor
to
> >IP
> >> address may be 1:N), so only useing the source IP as the key is enough.
Is
> >that
> >> ture? If it is, the IP address should be put into the first column in
the
> >> Generally, check should happen before create a new entry. While
creating a
> >> new
> >> entry first before checking whether the binding has already existed is
not
> >a

---

From: Dong Zhang <[email-masked]>
Date: Tue, 27 Apr 2010 11:10:23 +0800

Hi Guang,

I can't see the check whether a address binding has already existed in the BST or not in the new version draft. Maybe I miss. Acturally, what I am really concerned is that the check above would better be processed before creating the entry in any table. That's why I pointed out the issue of combining the Start state and Live state together.

BTW, for savi-dhcp-02, I have seen the diff with 01. It seems that savi-dhcp-02 has a number of changes. I am not quite sure whether there is a consensus for *each* change. At least, a chang log would be provided.

Thanks a lot.

>> >> perhaps. Thus, the state machine is a little bit simple.

------------------				 
Dong Zhang
2010-04-27

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 27 Apr 2010 13:49:17 +0800

Hi Dong,

Thank you for your comments.

The reason why a binding is setup even the address is in the BST is that it
is hard to determine whether to
1. keep the old one: it will prohibit movement
Or 2. delete the old one, setup the new one: a node may have multiple
anchors on the link

It is discussed in section 25. Thus we decide to
1. set up a binding if the procedure is finished;
2. keep a binding until the address is abandoned explicitly:
declined/released/anchor off-link. 

Change log will be added in a modified edition. Thanks for this advice.

BR,
Guang

Dong
> Zhang
> Sent: Tuesday, April 27, 2010 11:10 AM
> To: Guang Yao
> Cc: [email-masked]
> I can't see the check whether a address binding has already existed in the
BST
> or not in the new version draft. Maybe I miss. Acturally, what I am really
> concerned is that the check above would better be processed before
creating
> the entry in any table. That's why I pointed out the issue of combining
the Start
> state and Live state together.
> 
> BTW, for savi-dhcp-02, I have seen the diff with 01. It seems that
savi-dhcp-02
> has a number of changes. I am not quite sure whether there is a consensus
for
> *each* change. At least, a chang log would be provided.
> 
> 
> Thanks a lot.
> 
> >> >> right entry, it could check the anchor and the state. Since the
mapping
> >> >for
> >> I have found this problem. So I mentioned in my another comment,which
> said
> >> the
> >> Then, create the BST or FT. Thus, the IP address is able to be filled
into
> >the
> >> table as the key value.
> >>
> >> >>
> >> >> In section 11.1.2.3,
> >> >> >   assigned address is not bound with another anchor in current
BST.
> >If