For the record, I believe we should be cautious in not driving this
specification from too many implementation considerations, as there seem to be
more and more such arguments brought up.
I'd prefer a solid reliable secure
protocol than one that can be prototyped.
CPU was not my concern: It's
rather early/temporary state creation. There are numerous examples (tcp syn
attack is the best known) where creating states before the clinet is "confirmed"
(in our case before the client is granted with an address) opened the door for
nasty attacks.
thanks,
Jun Bi
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
Sent: Monday, November 02, 2009 9:20 PM
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 :
Dear WG members,
Please read the SAVI solution for DHCP.
This draft is for DHCP case. We removed the text on SLAAC of CPS-01 and
contributed to SAVI SLAAC draft.
This version have taken the suggestions
from Christian, Eric Levy-Abegnoli , Alberto García, etc. Thanks to all of
them.
Please provide your comments.
thanks,
Jun
Bi
SAVI Solution for
DHCPv4/v6
draft-bi-savi-cps-02.txt
Abstract
This document specifies
the procedure of setting up bindings between
DHCPv4
[RFC2131]/DHCPv6 [RFC3315] assigned source IP address and
anchor (refer to [SAVI-framework]) on SAVI (Source Address
Validation
Improvements) device. The bindings can be used to
filter packets with
forged IP addresses.
_______________________________________________
savi mailing list
savi at ietf.org
https://www.ietf.org/mailman/listinfo/savi
_______________________________________________
savi mailing list
savi at ietf.org
https://www.ietf.org/mailman/listinfo/savi