Re: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt

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

Dear Leaf,

 

Thank you for these advanced comments. Our responses are  as follows:

 

1.

Guang - R19: We found there is no direct link between SAVI devices, thus we
add a new link to illustrate this situation.

 

 

I guess we could live with the case of 'no direct link between SAVI
devices', just because the connection (i.e. Non-SAVI device) between them
are in the perimeter. 

 

Guang: You are right such a link is not necessary for real cases. But we
think it will be weird if we state "trust" is mainly used between direct
connected SAVI devices, but there is no such a case in the diagram.

 

2. 

 

Guang - R20: Since DHCP relay and server are only supposed to send DHCP
messages, data packets are not expected from them. If they also send data
packet, their roles are changed. How to process the data packet depends on
the the role which sends the data packet.

 

 

DHCP messages is only a kind of control plane packet. 

DHCP-Trust Attribute sounds only deactivate the blocking against the message
from server/relay.

 

If you let the data packet pass, then you will get a more flexible
application case as follows within the perimeter:



Right? I can't see the negative effect yet when you let the data packet pass
through the trust port of SAVI-switch.

 

 

Guang: Indeed, if only DHCP-trust if configured, the data packet will be
forwarded without checking. This point is specified in the doc. Thus, the
current design can survived in your case. However, this case is not secure;
thus, it is not a suggested deployment case. 



 

Best regards,

Guang

 

From: Leaf Yeh [mailto:[e-mail]] 
Sent: Tuesday, April 01, 2014 5:23 PM
To: 'Guang Yao'
Cc: [e-mail]; 'Jun Bi'; 'Ted Lemon'
Subject: RE: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt

 

Guang - R19: We found there is no direct link between SAVI devices, thus we
add a new link to illustrate this situation.

 

 

I guess we could live with the case of 'no direct link between SAVI
devices', just because the connection (i.e. Non-SAVI device) between them
are in the perimeter. 

 

 

Guang - R20: Since DHCP relay and server are only supposed to send DHCP
messages, data packets are not expected from them. If they also send data
packet, their roles are changed. How to process the data packet depends on
the the role which sends the data packet.

 

 

DHCP messages is only a kind of control plane packet. 

DHCP-Trust Attribute sounds only deactivate the blocking against the message
from server/relay.

 

If you let the data packet pass, then you will get a more flexible
application case as follows within the perimeter:



Right? I can't see the negative effect yet when you let the data packet pass
through the trust port of SAVI-switch.

 

 

Best Regards,

Leaf

 

 

 

-----Original Message-----
From: Guang Yao [mailto:[e-mail]] 
Sent: Tuesday, April 01, 2014 3:28 PM
To: 'Leaf Yeh'
Cc: [e-mail] <mailto:[e-mail]> ; 'Jun Bi'; 'Ted Lemon'
Subject: RE: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt

 

Hi Leaf,

 

Thank you very much for these comments! The replies are as follows.

 

1. Q19. I am not sure the reason why there is a new link between SAVI Device
C to SAVI Device B in Fig.1. The relation between the SAVI Device A and the
SAVI Device B looks more like the case described in the Fig.1 of SAVI arch.

(RFC7039).

 

R19:

We found there is no direct link between SAVI devices, thus we add a new
link to illustrate this situation.

 

 

2. Q20. As to DHCP-Trust Attribute,

in section 4.2.2, <quote>

The "DHCP-Trust Attribute" indicates the DHCP Server-Client messages

   from the corresponding attachment is trustable.

...

</quote>

, in section 4.3.2 <quote>

   (5)  Configure DHCP-Trust attribute on the direct attachments of

        trusted DHCP relays/servers.

...

DHCP-Trust

  attribute is only configured on the inside links of the perimeter.

   Only DHCP server-client messages originated in the perimeter is

   trusted.

</quote>

 

 

When the port of SAVI-switch connected to the trusted DHCP relays/servers
(in the SAVI-perimeter) is configured DHCP-Trust attribute, how about the
data packet forwarding when it is received on this port? I guess the switch
will forward the packet as the normal without checking, right? May you need
a statement on this case in section 8.1?

 

R20:

Thank you for this comment. 

Since DHCP relay and server are only supposed to send DHCP messages, data
packets are not expected from them. If they also send data packet, their
roles are changed. How to process the data packet depends on the the role
which sends the data packet.

We will specify this point in the revision.

 

-----Original Message-----

From: Leaf Yeh [ <mailto:[e-mail]>
mailto:[e-mail]]

Sent: Tuesday, April 01, 2014 9:51 AM

To: 'Guang Yao'

Cc:  <mailto:[e-mail]> [e-mail]; 'Jun Bi'; 'Ted Lemon'

Subject: RE: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt

 

Hi Guang,

 

Q19. I am not sure the reason why there is a new link between SAVI Device C
to SAVI Device B in Fig.1. The relation between the SAVI Device A and the
SAVI Device B looks more like the case described in the Fig.1 of SAVI arch.

(RFC7039).

 

 

Q20. As to DHCP-Trust Attribute,

in section 4.2.2, <quote>

The "DHCP-Trust Attribute" indicates the DHCP Server-Client messages

   from the corresponding attachment is trustable.

...

</quote>

, in section 4.3.2 <quote>

  (5)  Configure DHCP-Trust attribute on the direct attachments of

        trusted DHCP relays/servers.

...

DHCP-Trust

   attribute is only configured on the inside links of the perimeter.

   Only DHCP server-client messages originated in the perimeter is

   trusted.

</quote>

 

 

When the port of SAVI-switch connected to the trusted DHCP relays/servers
(in the SAVI-perimeter) is configured DHCP-Trust attribute, how about the
data packet forwarding when it is received on this port? I guess the switch
will forward the packet as the normal without checking, right? May you need
a statement on this case in section 8.1?

 

 

Best Regards,

Leaf

 

 

 

-----Original Message-----

From: savi [ <mailto:[e-mail]> mailto:[e-mail]] On
Behalf Of  <mailto:[e-mail]> [e-mail]

Sent: Monday, March 31, 2014 1:49 PM

To:  <mailto:[e-mail]> [e-mail]

Cc:  <mailto:[e-mail]> [e-mail]

Subject: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt

 

 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

This draft is a work item of the Source Address Validation Improvements
Working Group of the IETF.

 

        Title           : SAVI Solution for DHCP

        Authors         : Jun Bi

                          Jianping Wu

                          Guang Yao

                          Fred Baker

         Filename        : draft-ietf-savi-dhcp-21.txt

         Pages           : 43

         Date            : 2014-03-30

 

Abstract:

   This document specifies the procedure for creating a binding between

   a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI

   (Source Address Validation Improvements) device.  The bindings set up

   by this procedure can be used to filter out packets with forged

   source IP address in DHCP scenario.  This mechanism is proposed as a

   complement to ingress filtering to provide finer-grained source IP

   address validation.

 

 

The IETF datatracker status page for this draft is:

 <https://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/>
https://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/

 

There's also a htmlized version available at:

 <http://tools.ietf.org/html/draft-ietf-savi-dhcp-21>
http://tools.ietf.org/html/draft-ietf-savi-dhcp-21

 

A diff from the previous version is available at:

 <http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-21>
http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-21

 

 

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

 

Internet-Drafts are also available by anonymous FTP at:

 <ftp://ftp.ietf.org/internet-drafts/> ftp://ftp.ietf.org/internet-drafts/

 

_______________________________________________

savi mailing list

 <mailto:[e-mail]> [e-mail]

 <https://www.ietf.org/mailman/listinfo/savi>
https://www.ietf.org/mailman/listinfo/savi