Re: [savi] Some findings in the darft-ietf-savi-dhcp-20

["Guang Yao" <[e-mail]>]

Dear Leaf,

Thank you very much for your comments!

Your comments are very important and valuable. We have revised the doc accordingly and submitted a new version. The responses are both at the behind of this mail and in the attachment.

If you have any more comments, please let us know.

Best regards,
Guang

1. In the 1st paragraph of Page 11,
<quote>
For example, in Figure 1, the attachment from the Non-SAVI Device 1 to the SAVI Device B should be configured with no attribute.
</quote>

But in Fig.1, Non-SAVI Device 1 is not directly connected to SAVI Device B. I suppose the draft really means ‘SAVI Device C’ here.
***

R1:
Thank you very much!
We have made some modifications to the scenario diagram. It seems a part of the text is not updated accordingly. We have modified such sentences, including the following one.


2. In the last paragraph of page 11,
<quote>
In Figure 1, the attachment from the DHCP Relay to the SAVI Device B, and the attachment from the DHCP Server B to the SAVI Device B should be configured with this attribute.
</quote> (for DHCP-Trust Attribute)

But in Fig.1, DHCP Relay is not directly connected to SAVI Device B. I suppose the draft really means ‘SAVI Device A’ here.
***

R2.1:
Thanks. We have revised the sentence.

As to Fig.1, question for clarification : It sounds to set up a filter (as the requirement of DHCP-Trust Attribute) inside the SAVI-perimeter. I guess if the Relay or Server B is directly connected to SAVI Device and outside the SAVI-perimeter, we still need to set up DHCP-Trust Attribute for the port of SAVI Device A and B, right? If yes, does it means the Fig.1 can let the Relay or Server B outside the SAVI-perimeter?

R2.2:
Thank you for this comment.
Indeed, there is no problem if letting the Relay or Server B outside the perimeter. In fact, in the ealier versions, they are outside the perimeter.
However, in recent versions, we decide to include them into the perimeter. On one hand, it is used to distinguish the DHCP server A(which is outside the perimeter) and the DHCP server B/Relay. On the other hand, we think the perimeter should be used to separating the trusted area and the untrusted area. The Relay and Server B should be trusted, and they are actually the sources of trust.
Besides, to confirm with other solutions, perimeter is the place to perform data packet filtering. Thus, only the attach points with validating attribute are on the perimeter.

3. Question of clarification on the text in the 3rd paragraph of section 4.3.1,
<quote>
In this case, SAVI device B doesn’t create a binding for client A. SAVI device A doesn’t create a binding for client B. But the SAVI device B is still protected from spoofing from client A and the SAVI device A is still protected from spoofing from client B.
</quote>

What does “SAVI device B is still protected from spoofing from client A” exactly mean? How can SAVI device B protects from spoofing from client A? It sounds a little confused.

R3:
Thank you for this comment.
It means, "SAVI device B can avoid receiving spoofing traffic from client A.".


4. Question of clarification on the text in section 4.3.2,
<quote>
(6) Optional: configure filters on the upstream links to filter out
spoofing of local addresses from other networks.
</quote>

Per the definition of ‘Upstream link’ and ‘Downstream link’ in section 3, upstream is for other network (with gateway router), downstream is for local network. I guess the text here might mean ‘filter out spoofing of source addresses from other networks.’

R4:
Thank you for this comment.
We cannot prevent other networks from spoofing each other. Thus, we can just requre local addresses (addresses assigned to local network) will not be spoofed by the other networks.


5. Question of clarification on the text in the last paragraph of section 4.3.2,
<quote>
In this way, the points of attachments with Validating attribute (and
generally together with attachments of upstream devices) on SAVI
devices can form a perimeter separating DHCP clients and trusted
devices.
</quote>

The above sentence sounds SAVI devices always form perimeter for upstream devices. But in general thinking, we always trust devices in the upstream network. In Fig.1, we should not configure ‘DHCP-Trust attribute’ on the port of SAVI Device C for the Server A through Non-SAVI Device 1, which might means the Client A and Client B can’t get address assignment from Server A of the upstream network. Does the above sounds a little confused?

R5:
Thank you for this comment.
This problem is discussed in section4.3.3 P3.
We should not trust devices in the upstream network by default unless some other securty mechanisms are enforced.  Client A and Client B can get address assignment from Server A indirectly from the Relay.


6. Question of clarification on the text in the last paragraph of section 4.3.2,
<quote>
DHCP-Trust attribute is only configured on the inside links of the perimeter.
</quote>

The above sentence sounds, even in the SAVI-perimeter, we still need set up filter for some devices, including relay and server. It sounds we couldn’t trust the relay and server in the SAVI-perimeter; and after we configure the DHCP-Trust attribute on the port of the SAVI-device which connect the relay or server, we start to trust them. But in general thinking, we always trust devices in the perimeter, and we don’t need additional SAVI-device to connect some kind of device in the perimeter. Does the above sounds a little confused?

R6: 
Thank you for this comment.
Maybe this comment has been responed by R2.2?

7. Question of clarification on table 3 of BST in section 5:
<quote>
+---------+----------+----------+-----------+-------+
| Anchor | Address | State | Lifetime |TID |
+---------+----------+----------+-----------+-------+
| A | IP_1 | BOUND | 65535 |TID_1 |
+---------+----------+----------+-----------+-------+
| A | IP_2 | BOUND | 10000 |TID_2 |
+---------+----------+----------+-----------+-------+
| B | IP_3 |INIT_BIND | 1 |TID_3 |
+---------+----------+----------+-----------+-------+
</quote> for Binding State Table

It is not quite sure about ‘A’ and ‘B’ in the column of Anchor stands for. Does ‘A’ stands for the Client A? It must not stand for SAVI-Device A. ☺
Per the definition of ‘Binding anchor’ in section 3, the anchor is the link-layer property of Clients. It sound usually be the port of SAVI-device which connect Client A, right?

R7.1:
Thank you for this comment.
'A' and 'B' do not stand for any element in the diagram. They just denote some anchor of the clients.


On the other hand, I guess the ‘Creation Time’ of the entry looks like a field in this table per the usage described in the section 9. For the reason of consistency, we also have the field of ‘Creation Time’ in the FCFS-SAVI DataBase (i.e. SAVI-SLAAC DB, section 3.1 of RFC6620).

R7.2:
Thank you for this comment.
It is a good suggestion. But I think "Creation Time" is not requried in binding set up and traffic filtering. For the usage in section 9, the system time of the store operation is enough. There is no need to recording the "Creation Time" in binding set up. Besides, adding a new field in the table will introduce too many modifications...


8. In section 6.3,
<quote>
EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit
option is received.
</quote>

I guess  looks better than ‘EVE_DHCP_OPTION_RC, though I don’t really like the prefix of ‘EVE_’ here. ☺ The prefix of ‘EVE_’ must stand for Event here, supposed it really means the additional valid check defined in section 6.3.2.


R8:
Thank you for this comment.
We have changed ‘EVE_DHCP_SOLICIT_RC’ to ‘EVE_DHCP_OPTION_RC'. Yes, ‘EVE_’ stands for Event. We need some terms to denote events to be handled.


9. For Section 6.4.1, I think we could replace its title ‘From NO_BIND to Other States’ to be ‘From NO_BIND to INIT_BIND’.

R9:
Thank you for this comment.
Well, we find it is alright to make this modification.


10. In Section 6.4.3.2
<quote>
If the message is DHCPv6 Reply, the SAVI device checks each IA
Address option in each IA option.
</quote>
<quote>
The related binding entry can be determined based on
the address in the IAADDR option in the Leasequery-reply message.
</quote>

I personally like ‘IA Address option’ and ‘IAADDR option’ could written in the same.

R10:
Thank you for this comment.
We have changed them to 'IA Address option'.


11. In Section 7.1,
<quote>
Data packets
without matching binding entry may trigger this process to set up
bindings.
</quote>
<quote>
This process is not intended to set up a binding whenever a data
packet without matched binding entry is received.
</quote>

Does the above 2 sentence sound a little conflict?

R10:
Thank you for this comment.
"Data packets
without matching binding entry _may_ trigger this process to set up
bindings."

We use  a "may" to mean this is probable.


12. For Section 7.5.1, I think we could replace its title ‘From NO_BIND to Other States’ to be ‘From NO_BIND to DETECTION’.

R12:
Thank you for this comment.
Well, we find it is alright to make this modification, too.:)


13. In Section 7.5.3.2, about ‘IPv6 address’ on page 32,
<quote>
Send a Neighbor Solicitation message with the target address set
to the IP address in the corresponding entry. The Neighbor
Solicitation is only sent to the attachment which triggers the
binding. If there is no response after DAD_TIMEOUT, send
another Neighbor Solicitation.
</quote>

Could this additional DAD process be added in Fig.13?

R12:
Thank you for this comment. But it is there:
                               +-------------+
                               |             |
                     /---------|   NO_BIND   |<--------\
                     |  ------>|             |         | TIMEOUT
                     |  |      +-------------+         |(2nd LQ_DELAY)
   EVE_DATA_UNMATCH  |  |                              |
                     |  |                              |
                     |  |                              |
  ***1st DAD_TIMEOUT |  |                              | 1st LQ_DELAY
         /------\    |  |                              |    /---------\
         |      |    |  | EVE_DATA_CONFLICT            |    |         |
         |      v    v  |                              |    v         |
         |    +-------------+        TIMEOUT         +------------+   |
         |    |             | ***(2nd DAD_TIMEOUT)   |            |   |
         \----|  DETECTION  ------------------------>|  RECOVERY  ----/
              |             |                        |            |
              +-------------+                        +------------+
                                      EVE_DATA_LEASEQUERY|
                          /----------\                   |
            EVE_DHCP_RENEW|          |                   |
           EVE_DHCP_REBIND|    +-----v-------+           |
                          |    |             |           |
                          \----|   BOUND     |<----------/
                               |             |
                               +-------------+



14. In Section 7.5.3.2, about ‘IPv6 address’ in page 32,
<quote>
If there is only
one identical response, get the source hardware address from the
response. Check if the ’chaddr’ field (hardware address) of the
LEASEQUERY-REPLY message matches the source hardware address.
If the two addresses do not match, the following actions will
not be performed. If there is more than one response, if any of
the source hardware addresses matches the ’chaddr’ field
(hardware address) of the LEASEQUERY-REPLY message, the
following actions are to be performed.
</quote>

If the LEASEQUERY-REPLY message mentioned here is defined in RFC5007, I supposed we can’t find the ’chaddr’ field in this message.
***

R14:
We are sorry this is a careless copy from IPv4 para. LEASEQUERY-REPLY provides no additional information about the link-layer address or physical address of the client. Thus we remove this para.

15. Section 7.6, just after Fig. 12
<quote>
LQ_DELAY: MAX_LEASEQUERY_DELAY
</quote>

This ‘LQ_DELAY’ looks not a note for Fig. 12, but a note for Fig. 13, right? If yes, should it be placed after Fig. 13?

R15:
Thank you for this comment.
It has been done.

16. Section 14.2,
<quote>
[savi-fcfs]
Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFSSAVI:
First-Come First-Serve Source-Address Validation for
Locally Assigned Addresses", RFC 6620, May 2012.
</quote>

I prefer to replace [savi-fcfs] to be [RFC 6620].

R16:
Thank you for this comment.
It has been done.


17. Section 14.2,
<quote>
[savi-framework]
Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
"Source Address Validation Improvement Framework",
draft-ietf-savi-framework-06 (work in progress),
</quote>

I prefer to replace [savi-framework] to be [RFC 7039]. It is not is in the status of ‘work in progress’ any more. ☺

R17:
Thank you for this comment.
It is great!

18. I guess the darft-ietf-savi-dhcp-20 has not support DHCPv6-PD (RFC3633) for SAVI on the delegated prefix by now, right?

R18:
Thank you for this comment.
Actually, DHCPv6-PD is covered in the very early version of this draft. But it is moved to the section 7 of SAVI-Framework.

-----Original Message-----
From: Leaf Yeh [mailto:[e-mail]] 
Sent: Friday, March 28, 2014 1:05 AM
To: 'Jun Bi'; 'Jun Bi'; [e-mail]
Cc: 'Ted Lemon'; [e-mail]
Subject: Some findings in the darft-ietf-savi-dhcp-20

Dear Prof. Bi & authors,

I’ve read the main part of the darft-ietf-savi-dhcp-20, and probably got the following findings:

1. In the 1st paragraph of Page 11,
<quote>
For example, in Figure 1, the attachment from the Non-SAVI Device 1 to the SAVI Device B should be configured with no attribute.
</quote>

But in Fig.1, Non-SAVI Device 1 is not directly connected to SAVI Device B. I suppose the draft really means ‘SAVI Device C’ here.
***


2. In the last paragraph of page 11,
<quote>
In Figure 1, the attachment from the DHCP Relay to the SAVI Device B, and the attachment from the DHCP Server B to the SAVI Device B should be configured with this attribute. 
</quote> (for DHCP-Trust Attribute)

But in Fig.1, DHCP Relay is not directly connected to SAVI Device B. I suppose the draft really means ‘SAVI Device A’ here. 
***

As to Fig.1, question for clarification : It sounds to set up a filter (as the requirement of DHCP-Trust Attribute) inside the SAVI-perimeter. I guess if the Relay or Server B is directly connected to SAVI Device and outside the SAVI-perimeter, we still need to set up DHCP-Trust Attribute for the port of SAVI Device A and B, right? If yes, does it means the Fig.1 can let the Relay or Server B outside the SAVI-perimeter? 


3. Question of clarification on the text in the 3rd paragraph of section 4.3.1, <quote> In this case, SAVI device B doesn’t create a binding for client A. SAVI device A doesn’t create a binding for client B. But the SAVI device B is still protected from spoofing from client A and the SAVI device A is still protected from spoofing from client B. 
</quote>

What does “SAVI device B is still protected from spoofing from client A” exactly mean? How can SAVI device B protects from spoofing from client A? It sounds a little confused.


4. Question of clarification on the text in section 4.3.2, <quote>
(6) Optional: configure filters on the upstream links to filter out spoofing of local addresses from other networks.
</quote>

Per the definition of ‘Upstream link’ and ‘Downstream link’ in section 3, upstream is for other network (with gateway router), downstream is for local network. I guess the text here might mean ‘filter out spoofing of source addresses from other networks.’


5. Question of clarification on the text in the last paragraph of section 4.3.2, <quote> In this way, the points of attachments with Validating attribute (and generally together with attachments of upstream devices) on SAVI devices can form a perimeter separating DHCP clients and trusted devices.
</quote>

The above sentence sounds SAVI devices always form perimeter for upstream devices. But in general thinking, we always trust devices in the upstream network. In Fig.1, we should not configure ‘DHCP-Trust attribute’ on the port of SAVI Device C for the Server A through Non-SAVI Device 1, which might means the Client A and Client B can’t get address assignment from Server A of the upstream network. Does the above sounds a little confused?


6. Question of clarification on the text in the last paragraph of section 4.3.2, <quote> DHCP-Trust attribute is only configured on the inside links of the perimeter. 
</quote>

The above sentence sounds, even in the SAVI-perimeter, we still need set up filter for some devices, including relay and server. It sounds we couldn’t trust the relay and server in the SAVI-perimeter; and after we configure the DHCP-Trust attribute on the port of the SAVI-device which connect the relay or server, we start to trust them. But in general thinking, we always trust devices in the perimeter, and we don’t need additional SAVI-device to connect some kind of device in the perimeter. Does the above sounds a little confused?


7. Question of clarification on table 3 of BST in section 5:
<quote>
+---------+----------+----------+-----------+-------+
| Anchor | Address | State | Lifetime |TID |
+---------+----------+----------+-----------+-------+
| A | IP_1 | BOUND | 65535 |TID_1 |
+---------+----------+----------+-----------+-------+
| A | IP_2 | BOUND | 10000 |TID_2 |
+---------+----------+----------+-----------+-------+
| B | IP_3 |INIT_BIND | 1 |TID_3 |
+---------+----------+----------+-----------+-------+
</quote> for Binding State Table

It is not quite sure about ‘A’ and ‘B’ in the column of Anchor stands for. Does ‘A’ stands for the Client A? It must not stand for SAVI-Device A. ☺ Per the definition of ‘Binding anchor’ in section 3, the anchor is the link-layer property of Clients. It sound usually be the port of SAVI-device which connect Client A, right?

On the other hand, I guess the ‘Creation Time’ of the entry looks like a field in this table per the usage described in the section 9. For the reason of consistency, we also have the field of ‘Creation Time’ in the FCFS-SAVI DataBase (i.e. SAVI-SLAAC DB, section 3.1 of RFC6620).


8. In section 6.3,
<quote>
EVE_DHCP_OPTION_RC: A DHCPv6 Solicitation message with Rapid Commit option is received.
</quote>

I guess ‘EVE_DHCP_SOLICIT_RC’ looks better than ‘EVE_DHCP_OPTION_RC, though I don’t really like the prefix of ‘EVE_’ here. ☺ The prefix of ‘EVE_’ must stand for Event here, supposed it really means the additional valid check defined in section 6.3.2.


9. For Section 6.4.1, I think we could replace its title ‘From NO_BIND to Other States’ to be ‘From NO_BIND to INIT_BIND’.


10. In Section 6.4.3.2
<quote>
If the message is DHCPv6 Reply, the SAVI device checks each IA Address option in each IA option.
</quote>
<quote>
The related binding entry can be determined based on the address in the IAADDR option in the Leasequery-reply message.
</quote>

I personally like ‘IA Address option’ and ‘IAADDR option’ could written in the same. 


11. In Section 7.1,
<quote>
Data packets
without matching binding entry may trigger this process to set up bindings.
</quote>
<quote>
This process is not intended to set up a binding whenever a data packet without matched binding entry is received.
</quote>

Does the above 2 sentence sound a little conflict?


12. For Section 7.5.1, I think we could replace its title ‘From NO_BIND to Other States’ to be ‘From NO_BIND to DETECTION’.


13. In Section 7.5.3.2, about ‘IPv6 address’ on page 32, <quote> Send a Neighbor Solicitation message with the target address set to the IP address in the corresponding entry. The Neighbor Solicitation is only sent to the attachment which triggers the binding. If there is no response after DAD_TIMEOUT, send another Neighbor Solicitation.
</quote>

Could this additional DAD process be added in Fig.13?

　　
14. In Section 7.5.3.2, about ‘IPv6 address’ in page 32, <quote> If there is only one identical response, get the source hardware address from the response. Check if the ’chaddr’ field (hardware address) of the LEASEQUERY-REPLY message matches the source hardware address.
If the two addresses do not match, the following actions will not be performed. If there is more than one response, if any of the source hardware addresses matches the ’chaddr’ field (hardware address) of the LEASEQUERY-REPLY message, the following actions are to be performed.
</quote>

If the LEASEQUERY-REPLY message mentioned here is defined in RFC5007, I supposed we can’t find the ’chaddr’ field in this message.
***


15. Section 7.6, just after Fig. 12
<quote>
LQ_DELAY: MAX_LEASEQUERY_DELAY
</quote>

This ‘LQ_DELAY’ looks not a note for Fig. 12, but a note for Fig. 13, right? If yes, should it be placed after Fig. 13?


16. Section 14.2,
<quote>
[savi-fcfs]
Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFSSAVI:
First-Come First-Serve Source-Address Validation for Locally Assigned Addresses", RFC 6620, May 2012.
</quote>

I prefer to replace [savi-fcfs] to be [RFC 6620].



17. Section 14.2,
<quote>
[savi-framework]
Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement Framework",
draft-ietf-savi-framework-06 (work in progress), </quote>

I prefer to replace [savi-framework] to be [RFC 7039]. It is not is in the status of ‘work in progress’ any more. ☺


18. I guess the darft-ietf-savi-dhcp-20 has not support DHCPv6-PD (RFC3633) for SAVI on the delegated prefix by now, right?


Anyway, I am not yet aware the discussion history in SAVI-WG before; the above might be some additional comments, might  be something discussed before.  Hope some of the above could be a help for the text in this draft,  and I am really looking forwarding to the advance of this draft-ietf-savi-dhcp.


Best Regards,
Leaf