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

From: "Guang Yao" <[email-masked]>
Date: Tue, 1 Apr 2014 15:22:34 +0800

Dear Leaf,

Thank you very much for the quick review!

Our responses are as follows:

1. Leaf - 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?
Guang - R2.2: ...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. 

The above decision sounds you make that Relay is the for the connection with the upstream network.

Guang:
Thank you for this comment.
 Exactly. The strength of the binding based security is actually very weak. Especially, if the DHCP messages are untrustable, the bindings will be meaningless. Thus, We prefer the security mechanism enforced between DHCP relay and server, if we cannot completely trust traffic from upstream.

2. Guang - 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. 

But you still need DHCP-Trust Attribute for them. It seem DHCP-Trust Attribute make them to be trust. How about if we just trust the Relay and Server B in the SAVI-perimeter without the additional permission, because they are connected to the Trust Port, (which was introduced by RFC662.)

Guang: 
Thank you for this comment.

Trust: both data packet and control packet are trusted;
DHCP-Trust: only control packet is trusted.

Actually it is proper to configure Trust on the port of Relay and server B, if we also trust the data packet from them. In the scenario, the relay and server B are supposed to only send control packets, thus I think it makes no difference whether DHCP-Trust or trust is used. (Maybe we should specify this point in the doc?)

However, I believe it is necessary to distinguish the two types of trusts.  I think the perimeter is only a deployment suggestion. In practice it is not always possible to enforce savi as the diagram.  For example, we may choose to configure DHCP-trust and validating on the same port, which is attached by a DHCP server and some hosts through a hub. In such cases, the DHCP server is actually outside the perimeter. The DHCP messages are not fully trustable but we have to make use of them for there are no other ways. 

Besides, I think where to draw the perimeter is actually not a critical problem. It makes no difference whether placing the relay and server inside or outside the perimeter. The savi device works based on port configuration, without knowing the perimeter.

3. Guang - 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.

It make me not quite sure you want to configure Validating attribute for the upstream network, which looks outside of the SAVI-perimeter in Fig.1. 

Per the description in section 4 of RFC7039, <quote>The IP source addresses in packets passing the protection perimeter are validated by the ingress SAVI instance, but no further validation takes place as long as the packets remain within or leave the protection perimeter.</quote>, I suppose it is not necessary to let upstream network outside the SAVI-perimeter.

Guang:
Thank you for this comment.
It's my fault: the upstream port is also on the perimeter.
We choose not to fully trust the traffic from upstream network: both data packet and control packet. Thus, I think it is necessary to keep it outside the perimeter. 
However, if the operator chooses to fully trust packet from upstream networks, he can use a Trust on the corresponding port. Then in concept the upstream network is inside the perimeter.

4. Leaf - 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.
Guang - R3:...It means, "SAVI device B can avoid receiving spoofing traffic from client A.".

The above statement sounds SAVI device A can avoid receiving spoofing traffic from client A, then 'SAVI device B can avoid receiving spoofing traffic from client A' because of the SAVI perimeter. I doubt the necessary text of 'SAVI device B is still protected from spoofing from client A' here.

Guang:
Thank you for this comment.
We will revise this sentence.

5. Leaf -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>...
Guang - R4:...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.

Thanks for your explanation here, but that method sounds ingress filtering (or uRPF) to me. Meanwhile, the 'other network' in the definition of 'Upstream link' seems a little vague for me. I guess it is usually we don’t use SAVI-switch to connect to the upstream network, we use a gateway or router. So the (6) of SAVI-DHCP Perimeter Configuration Guideline seems unnecessary. I mean we don't usually use SAVI-switch to form the SAVI-perimeter against the upstream link or network.

Guang:
Thank you for this comment.
We do not require the savi switch to connect to upstream network. Actually, they are connected to the gateway or router. This configuration just specifies how to process the traffic from the gateway or router.

6. Leaf - 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...
Guang - R5:...We should not trust devices in the upstream network by default unless some other securty mechanisms are enforced.  

Why not if the upstream network is in the SAVI-perimeter?

Guang:
Thank you for this comment.
For SAVI-DHCP, a critical problem is that the DHCP Server-Client messages should be trustable. However, there can be bogus DHCP servers in the upstream network. We should not make assumption that the upstream network is always trustable. Thus, they should not be in the perimeter.

7. Guang - R7.1: ...'A' and 'B' do not stand for any element in the diagram. They just denote some anchor of the clients.

How about replace A to be 'Port_1' in the instance of Fig.3?

Guang:
Thank you for this comment. This is an excellent advice. We will revise the doc accordingly.

8. Leaf - 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).
Guang - R7.2:...It is a good suggestion. ... 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...

Per the description in section 9, <quote> Binding entries MAY be saved into non-volatile storage whenever a new binding entry changes to BOUND state. ... The time when each binding entry is established is also saved.</quote>, I suppose 'Creation Time' could support this action.

Guang:
Thank you for this comment. Maybe can the  'Creation Time' field only present in the stored table rather than BST?

9. Leaf...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.
Guang - R8: ...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.

I guess the text in the draft will not cause any misunderstanding if you delete the prefix of 'EVE_'. Right?

Guang:
Thank you for this comment. "EVE_" means it is an event instead of a packet. For example, not all " DHCP_OPTION_RC'" will trigger an event.

10. Leaf - 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?
Guang - R10: ... "Data packets without matching binding entry _may_ trigger this process to set up bindings." We use a "may" to mean this is probable.

Can I say ' This process is intended to set up a binding whenever a data packet without matched binding entry is received.' ?

Guang:
Thank you for this comment. Strictly, it is not quite proper. Not all the mismatched packet will trigger the process.

11. 
Leaf -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?
Guang - R12: ... But it is there:...

I am not quite sure it is a good decision to delete this DAD process after EVE_DATA_LEASEQUERY (in the state of RECOVERY). It looks not the same as that DAD after EVE_DATA_UNMATCH (in the state of DETECTION), if you keep the text in section 7.5.2, <quote>The messages MUST NOT be sent to the attachment from which the triggering packet is received.</quote>. The DAD process after EVE_DATA_LEASEQUERY looks that 'The Neighbor Solicitation is only sent to the attachment which triggers the binding.' I personally prefer to combine these 2 DAD process, which means to sent DAD_NS to all the ports of SAVI-switch.

Guang:
Thank you for this comment.
As I can understand, you mean sending DAD to the attachment which triggers the binding after receiving the DHCP leasequery-reply? What is the purpose of this step?
And I'm wondering how to combine the 2 DAD processes since they are performed at different stages?
May you please give a further explanation? Thank you very much!

Best regards,
Guang

-----Original Message-----
From: Guang Yao [mailto:[email-masked]]
Sent: Monday, March 31, 2014 5:33 PM
To: 'Leaf Yeh'; 'Jun Bi'; 'Jun Bi'
Cc: 'Ted Lemon'; [email-masked]
Subject: RE: Some findings in the darft-ietf-savi-dhcp-20

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.

---

From: "Leaf Yeh" <[email-masked]>
Date: Wed, 2 Apr 2014 17:14:20 +0800

1. Guang - R2.2: ...Indeed, there is no problem if letting the Relay or Server B outside the perimeter. ..., in recent versions, we decide to include them into the perimeter.

Leaf - The above decision sounds you make that Relay is the for the connection with the upstream network.

Guang - Exactly. 

The basic questions here sounds : Do we need Server B/Relay work outside the perimeter? Per the draft-(ver.)21 of today, I guess the answer is 'no'. J

2. Guang - Trust: both data packet and control packet are trusted;

However, I believe it is necessary to distinguish the two types of trusts.  

For the thinking of additional modular for the switch, DHCP-Trust attribute is designed for anti-bogus DHCP server/Relay. It is only used for the access of DHCP server/Relay, just because the default (No attribute) is blocking the messages from the Server/Relay on all ports (including validating ports) on the SAVI-switch, right?

Can we just use DHCP-Trust take care the DHCP (control) messages from the Server/Relay, and not care the data (plane) packet? I mean it might be enough for the defense against bogus DHCP server/Relay, right?

Guang - I think the perimeter is only a deployment suggestion. In practice it is not always possible to enforce savi as the diagram.  

Then I suggested to make the Fig.1 in the draft more popular for the real practice (or networking deployment). In my mind, the basic application scenario looks like the following:

Guang - For example, we may choose to configure DHCP-trust and validating on the same port, which is attached by a DHCP server and some hosts through a hub. In such cases, the DHCP server is actually outside the perimeter. The DHCP messages are not fully trustable but we have to make use of them for there are no other ways.

That sounds the DHCP server can be outside SAVI-perimeter and DHCP-Trust can be used on the perimeter with Validating port.

Guang - Besides, I think where to draw the perimeter is actually not a critical problem. It makes no difference whether placing the relay and server inside or outside the perimeter. The savi device works based on port configuration, without knowing the perimeter.

The concept of 'perimeter' is defined in section 4 of RFC7039 (SAVI arch.) and section 2.5 of RFC6620 (SAVI-SLAAC). It looks to me the Validating port of SAVI-Switch (for SLAAC) and the Validating attribute of the SAVI devices (for DHCP) forms the perimeter. In another word, the binding filters of SAVI form the perimeter, though draft-SAVI-DHCP adds more discussion 'On the Placement of DHCP Server/Relay' at section 4.3.3.

...

Guang - It's my fault: the upstream port is also on the perimeter.

 

That is really my concern:

a.  I don't think we really need SAVI switch (and its validating attributes) to form the perimeter against the upstream network in practice.

b .  If you don't trust the traffic from the upstream network, then the methods, such as ingress filtering or uRPF, other than SAVI might be employed.

c.  I guess we have not a clear definition for the upstream network. In my mind, the upstream network mention here sounds in the same administrative domain of the operator, which we could trust.

Leaf - Thanks for your explanation here, but that method sounds ingress filtering (or uRPF) to me. Meanwhile, the 'other network' in the definition of 'Upstream link' seems a little vague for me. I guess it is usually we don’t use SAVI-switch to connect to the upstream network, we use a gateway or router. So the (6) of SAVI-DHCP Perimeter Configuration Guideline seems unnecessary. I mean we don't usually use SAVI-switch to form the SAVI-perimeter against the upstream link or network.

Guang: ... We do not require the savi switch to connect to upstream network. Actually, they are connected to the gateway or router. This configuration just specifies how to process the traffic from the gateway or router.

The draft sounds only about SAVI-switch. The configuration guideline & state machines only work for switches (i.e. SAVI devices), right? 

6. Guang: ...For SAVI-DHCP, a critical problem is that the DHCP Server-Client messages should be trustable. However, there can be bogus DHCP servers in the upstream network. We should not make assumption that the upstream network is always trustable. Thus, they should not be in the perimeter.

I suppose the SAVI protection perimeter is not suitable against the upstream network, for at least 2 reasons:

a.  we don't use SAVI device to connect the upstream network;

b.  we don't use Validating attribute for the upstream network;

I guess your perimeter (SAVI-DHCP perimeter) here sounds not the same as SAVI protection perimeter defined in RFC7039 (SAVI arch.) and RFC6620 (SAVI-SLAAC). I can't find words in the above 2 RFCs on that we can't trust the data or even control packets from the upstream network, or the statement of ' We should not make assumption that the upstream network is always trustable '.

If you doubt there is a bogus DHCP server in the upstream network, you might employ something like 'DHCP-trust attribute' configure on the router (or gateway) to block DHCP server-client messages from the upstream network, then you could only use the local trustable DHCP server between the SAVI-perimeter and the router, or use DHCP relay to connect the remote trustable DHCP server. But the date (plane) packet need pass through, from the upstream network, access network, SAVI perimeter to the end-user hosts (i.e. DHCP clients).

But this sounds not a feature of SAVI-switch, and might be out-of-scope of the draft. I prefer 'DHCP-trust attribute' could only mention for the SAVI device in this draft.

8. Guang:'Creation Time' field only present in the stored table rather than BST?

I believe the solution in draft-SAVI-DHCP-21 can work, but the solution in RFC6620 sounds better. If one want to implement both SAVI-SLAAC & SAVI-DHCP, he might want the same binding table. Right?

9. Leaf- I guess the text in the draft will not cause any misunderstanding if you delete the prefix of 'EVE_'. Right?

Guang: Thank you for this comment. "EVE_" means it is an event instead of a packet. For example, not all " DHCP_OPTION_RC'" will trigger an event.

For example, you can’t find ‘EVE_’ for those messages which act as the event to trigger the state-change described in RFC6620, you still can understand it.

10. Leaf - 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>

Leaf - Can I say ' This process is intended to set up a binding whenever a data packet without matched binding entry is received.' ?

Guang: … Strictly, it is not quite proper. Not all the mismatched packet will trigger the process.

Can I say ‘This process may not intended to set up a binding whenever a data packet without matched binding entry is received.’ or ‘This process may intended to set up a binding whenever a data packet without matched binding entry is received.’? I am just not sure about the wording in ‘This process is not intended to set up a binding whenever a data packet without matched binding entry is received.’. Anyway, it makes me a little confused. In my mind, the process does intend to do something.

11. Leaf - …if you keep the text in section 7.5.2, <quote>The messages MUST NOT be sent to the attachment from which the triggering packet is received.</quote>. The DAD process after EVE_DATA_LEASEQUERY looks that 'The Neighbor Solicitation is only sent to the attachment which triggers the binding.' I personally prefer to combine these 2 DAD process, which means to sent DAD_NS to all the ports of SAVI-switch.

Guang: …As I can understand, you mean sending DAD to the attachment which triggers the binding after receiving the DHCP leasequery-reply? What is the purpose of this step? And I'm wondering how to combine the 2 DAD processes since they are performed at different stages? May you please give a further explanation?

Draft-(ver.)20 has the 2nd DAD process after EVE_DATA_LEASEQUERY (in the state of RECOVERY). Draft-(ver.)21 also have the 2nd ARP process for IPv4 address in same section 7.5.3.2. 

I guess the purpose of this process is double-check that one client (or host) assigned the address (specified in the Lease-query) with the valid lease is actively attached on the port which received a data without matched binding entry. 

I suppose the target address in the 2nd DAD process is the same as that in the 1st DAD process, which is the source address of the data packet received in the EVE_DATA_UNMATCH, right? If yes, that make possible to combine these 2 processes.

Best Regards,

Leaf

-----Original Message-----
From: Guang Yao [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2014 3:23 PM
To: 'Leaf Yeh'; 'Jun Bi'; 'Jun Bi'
Cc: 'Ted Lemon'; [email-masked]
Subject: RE: Some findings in the darft-ietf-savi-dhcp-20

Dear Leaf,

Guang:

 

 

Guang: 

 

 

Guang:

 

 

Guang:

 

 

 

Guang:

 

 

Guang:

 

 

Guang:

 

 

Guang:

 

 

Guang:

 

 

 

Guang:

 

11. 

 

Guang:

Best regards,

Guang

---

From: "Guang Yao" <[email-masked]>
Date: Fri, 4 Apr 2014 11:42:37 +0800

Dear Leaf,

Thank you very much for these comments! Our responses are as follows:

1. 

Guang - Exactly. 

The basic questions here sounds : Do we need Server B/Relay work outside the perimeter? Per the draft-(ver.)21 of today, I guess the answer is 'no'. :)

Guang: cheers!

2. 

Guang:

Yes.

Guang:

If DHCP-Trust is used alone, data packet will not be checked. Maybe there is some misunderstanding here? Data packet check is only performed on “Validating” port.

3. 

Guang: I can understand your scenario. Actually, this is the original scenario of SAVI-DHCP. However, from some reviewers, bogus DHCP servers from the upstream networks are possible security threat. If we choose fully trust traffic from upstream networks, this mechanism is actually fragile. Thus, at last, we choose the current design.

Anyway, the guidelines are just suggestions to make the deployment secure. If the operator chooses trust the upstream networks, it is alright to configure Trust on the upstream port. But it should understand this security threat.

4. 

Guang: Exactly. But such a case will introduce security problem. If we have no better choices, such a configuration is possible.

5. 

Guang:

Exactly. A difference is that SAVI-DHCP choose not trust DHCP messages from upstream network. For SAVI-FCFS, there is no such a problem.

6.

Guang:

As we specified in the doc, the upstream network is actually all the other networks, i.e., the other part of the Internet.

In this mechanism, we make no assumption on how the upstream networks are operated, and whether filtering is performed on the gateway or router(actually, ingress filtering or uRPF is not able to filter bogus DHCP messages). It is a too strong assumption that the traffic from all the other networks can be trust.

Again, we must claim that the guidelines are just suggestions.

7.

Guang:

a.       As we state, it is a suggestion. Besides, the gateway/router itself can be regarded as SAVI device if  it helps filtering bogus DHCP messages.

b.       We don’t use this, either. :)

Guang:

For SAVI-FCFS, it is totally OK if the upstream network is untrustable, because this mechanism can work with only local messages. However, for SAVI-DHCP, it is different.

Guang:

First, we do not filter data traffic from upstream networks… Second, it is totally OK to treat router (or gateway) as SAVI devices by  configuring DHCP Trust.

8.

Guang:

I cannot see why using additional memory to keep a useless field in running time is better…

Guang:

That’s a good reason. But we are going to modify this naming if only misunderstanding is caused by the prefix. There is no misunderstanding with the current naming, right?

 

Guang: 

We just want to emphasize “no all the data packet will trigger this process”.

 

Guang:

Well I see. It is a good reason.

Guang:

Actually not. The first is to avoid the attack against a local address. If a local conflict is found, there is no need to perform lease-query, as the procedure is costly.

Best regards,

Guang

From: Leaf Yeh [mailto:[email-masked]] 
Sent: Wednesday, April 02, 2014 5:14 PM
To: 'Guang Yao'; 'Jun Bi'; 'Jun Bi'
Cc: 'Ted Lemon'; [email-masked]
Subject: RE: Some findings in the darft-ietf-savi-dhcp-20

Guang - Exactly. 

The basic questions here sounds : Do we need Server B/Relay work outside the perimeter? Per the draft-(ver.)21 of today, I guess the answer is 'no'. :)

 

 

 

 

 

 

 

 

...

 

 

 

 

 

 

 

 

 

 

 

 

 

Best Regards,

Leaf

-----Original Message-----
From: Guang Yao [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2014 3:23 PM
To: 'Leaf Yeh'; 'Jun Bi'; 'Jun Bi'
Cc: 'Ted Lemon'; [email-masked] <mailto:[email-masked]> 
Subject: RE: Some findings in the darft-ietf-savi-dhcp-20

Dear Leaf,

Guang:

 

 

Guang: 

 

 

Guang:

 

 

Guang:

 

 

 

Guang:

 

 

Guang:

 

 

Guang:

 

 

Guang:

 

 

Guang:

 

 

 

Guang:

 

11. 

 

Guang:

Best regards,

Guang