|
Dear Eric,
In response your comment on using option 82 to store the
port info to reduce the "START" state,
we consulted some vendors, not all DHCP servers support
option 82, so that might be a problem when the SAVI
device is widely deployed. Another response
from the switch vendor is that inserting the option in DHCP packet
is estimated to consume the similar or more CPU resource
than creating a "START" state.
There is one situation that if the anchor is MAC (need
the MAC is unspoofable, by deploying some IEEE tech such 802.1ae/af,
which is not the common case), then the "START" state is
not needed.
Anyway, thank you very much for your valuable comments,
and we are considering to adopt your suggestion as
an option (or open issue) in the draft.
thanks,
Jun Bi
From: Bi Jun
Sent: Tuesday, November 03, 2009 6:45 PM
Subject: Re: [savi] SAVI Solution for DHCPv4/v6 Dear Eric,
Thank you very much for your comments.
Please see my reply below.
Best Regards,
Jun Bi
From: Eric Levy-Abegnoli
Sent: Monday, November 02, 2009 9:20 PM
To: Bi Jun
Subject: Re: [savi] SAVI Solution for DHCPv4/v6 Jun Bi and all,
I think the document is a reasonnably good shape. I had however a few substantial comments made offline, that I'd like to repeat the mailing list (note that they are all listed already in the doc as open issues, but the RA filtering) - Section 9.4: Router Advertisements have nothing to do with the SAVI charter. For that, there is draft-ietf-v6ops-ra-guard. So I don't think it belongs here or in the framework document. bj: A good suggestion. The address prefix
configuration security is very important for source address validation, so the
SAVI draft must
mention it. Since there is a
related draft, we plan to move this part into the "security consideration".
After the draft-ietf-v6ops-ra-guard is
finalized (as a RFC), if at that time, the solution in that rfc works for SAVI
requirement, then we remove the text and state that the SAVI device
must conform to that rfc.
- Section 7 (and subsequent) I don't like the idea of creating a state "START" on the request, and I think in most cases, the state creation could happen on the reply. Otherwise, there is an obvious DoS attack that would fill the binding table with as many "START" entries as allowed (max described in section 16 help protecting the box, but not the anchor) and prevent legitimate entries to be created. From my reading, a state "START" is created upon receiving a REQUEST message. In most cases, creating the state on the REPLY should work and be a lot safer. That is whenever the REPLY have enough information to create the entry and associate it with the requesting anchor. For instance, if the anchor is the MAC, then the response has it. If the anchor is the port, upon receiving the REPLY, it can be found in the option 82. And if there is no option 82 (I am wondering if the switch could not insert it all the time?), then there is the switch L2 mapping table. So I'd like this state to be removed or a least used as an "optionnal but dangerous" correlation mechanism. bj: In our opinion, the most
scenarios will be SAVI-host connections. In that case, host directly attached to
SAVI-host port, so there is be no
security threaten in this
case. If a non-savi switch is connected to SAVI-poly port, what you mentioned
might be a problem. But please note that
if we remove this state, then if the
MAC-port mapping table is poisoned by an attacked launched between REQUEST and
REPLY, the SAVI switch
will lost the source port, there will
another security threaten (with this "START" state, the REPLY can be
forwarded to the correct source port by
the binding table when the MAP-port mapping table
is changed). Therefore by trading off, we intend to keep it (but will consider
to mentioned the
potential problem for SAVI-poly port).
Actually, the SAVI-ploy port (A SAVI
switch connects to a non-SAVI switch) is really not recommend indeed in our
opinion, because it can not achieve the host-granularity anti-spoofing, which is
very import for security, management and billing purposes. The only case I
believe the SAVI-poly case is useful is that a person in a office connect a hub to SAVI-switch,
then connect his multiple hosts to the hub (as the case we discussed with Marcelo, Erik, Christian on the last day of IETF
75). In this case, I think the user should be reasonable for the
attacking between his own hosts).
- My other substantial comment is about the interactions between ND (or ARP) and DHCP. My understanding of DHCP is that it is the client responsability to verify the address uniqueness and to DHCPDECLINE in case of a collision. So it should be sufficient to refer to DHCP messages, and if not, i'd like to see the rational for it. I have also suggested that whatever additional interactions there maybe should rather be described in the framework document. bj: Even it is a client's resposability to verify the
address uniqueness, the SAVI device must make sure the client have done
it.
If the client didn't complete the DAD procedure, the SAVI device has the right
to drop the packets as a punishment.
Eric Bi Jun a écrit :
_______________________________________________ savi mailing list savi at ietf.org https://www.ietf.org/mailman/listinfo/savi |
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.