Subject: [savi] 转发: 答复: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]

From: "Guang Yao" <[email-masked]>
Date: Tue, 28 Oct 2008 10:40:28 +0800

-----邮件原件-----
发件人: Guang Yao [mailto:[email-masked]] 
发送时间: 2008年10月28日 2:47
收件人: 'marcelo bagnulo braun'
主题: 答复: [savi] 答复: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]

-----邮件原件-----
发件人: marcelo bagnulo braun [mailto:[email-masked]] 
发送时间: 2008年10月28日 1:16
收件人: Jun Bi
抄送: Guang Yao; [email-masked]
主题: Re: [savi] 答复: [Fwd: I-D Action:draft-bagnulo-savi-send-00.txt]

Jun Bi escribió:
> Dear Marcelo,
>
> Thank you for your contribution to the WG.
>
> I fully support a solution with SeND. But a solution should handle the
> spoofable MAC address.
> So if you want your solution work, please do more work to fix it.
>
> CERNET (china education and research network) run 2000 university
> campus networks. We found the MAC address is spoofable, at least in 2
> cases:
> 1) If you access with a WiFi AP, which is the common case in campus
> network,
> 2) MAC can be spoofed when using a HUB (multiple MAC addresses per
> link, as charter said). Using a hub is a common situation for at least
> 1/2 universities for the dormitory network.
>
So any idea how would any solution would provide the level of security
you ask for and complies with the current charter, in particular with
the constraint of not changing the hosts?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I think with the constraint of not changing the hosts, the only possible way

Is using a switch mechanism to filter normal data packet and using SeND to 
handle mobility at layer2 and other special issues.
(But here is still a rather strong precondition that the SeND has been
enabled.)
And I think your mechanism is secure if you restrict it as a switch
mechanism.
Your mechanism and IP Source Guard are both in the correct direction in a
switch LAN.
Actually I discussed with an engineer of Cisco, his group is implementing
the IP Source Guard for IPv6.
And I found they were using SeND to handle layer-2 mobility.
Maybe you can first adapt your mechanism for a switch network, to avoid the
argument on its security in a non-switch network.
In my opinion, there is no way to achieve strict security with the
constraint of no host change when there is no switch in the network.
That is not the fault of your mechanism. The solution is not there.

I mean, it is not only because the charter says so, but because we need
to define a solution that is deployable. IMHO requiring hosts changes
for this is a non starter.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IMHO, host change is a non starter, but is an ending. If we constrain there
should be no host change when finding more secure ND, there will
be no SeND. SeND is successful so we modify our host to employ SeND. And for
source address validation, I think the situation may be much the same.

I think a solution like SeND SAVI or FCFS SAVI that don't requires host
changes is not perfect but styill is an increment of the current
situation and the deployment model seems to me quite strong.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I agree with you. That is all we can do now. We have tried all the possible
methods and now we found it's clear what we can achieve is limited.
It is better but far from a real security. 
Since all the existing protocols are not designed for source address
validation, why we must persist that we can achieve a great result by taking
advantage of them?
>
> Could you please estimate how much the memory it requires?
> Right now I don't mean it doesn't work, I mean in engineering, please
> give us the analysis or do an implementation and testing.
> Giving the quantity analysis will be helpful to investigate the
> feasibility.
>

Well, i would argue that this is similar to an ARP cache actually.
I mean the attacker could send more packets with different mac
addresses. The result is that the DB will overflow. No problem, since
the SAVI function will ask for a new NA again. This result in more
traffic, but there is no amplification.

regards, marcelo

>
>> OTOH, you know who the
>> attacker is, sicne you have it identified
>>
>> regards, marcelo
>
> In WiFi case and HUB case, if it is attacked with spoofed MAC address,
> then it world be hard to know who is the attacher.
>
> thanks,
> Jun Bi
>
>
>
>
>