eap Mailing List: Re: network discovery & selection: problem definition

[Jari Arkko (jari.arkko]

Michael Richardson wrote:

>     Jari> We could call this the "payload route binding problem". In this
>     Jari> problem, authentication and l2 support do not guarantee that
>     Jari> the packets are actually routed through the path that appears to have
>     Jari> been offered. Basically, if I have a flat fee account *and* a deal 
>
>   If I took a shared key from the EAP EMSK somewhere, and used that to
> authenticate the DHCP server (3118), it might have a serious positive
> benefit. 
>
>   In v6 land, we could use the channel created by EAP to provide the
> certificates for the SEND secured RA. Both ways, that means that we are 
> sure we are speaking at layer 3 to the services that we authenticated at
> layer two.

This is interesting. But, as far as I can see, this does not completely 
solve
the problem. In v4, the attacking node would simply offer its own DHCP
server, the user would authenticate it and get an internal IP address
from it. Then the attacking node would NAT all the packets to an
address provided by the real bandwidth provider.

The situation isn't much better in v6, except that we might perhaps expect
or even verify that there is no NATs in between. If we could do that, then
the RA signatures are sufficient to bind our own address - router - access
authentication together.

And if the attacker tunnels everything through the access
network to a centrally placed server, then neither EMSK or
RA certs are going to be very helpful. But in this case
the attacker would have to provide at least some central
bandwidth, even if he can skip the provisioning of the
access network.

I'm ccing Bob because he was recently interested in certificates
handed out from L2.

>   I'd like a way to avoid the attack by careful network selection.
>   If you think it is out of scope - that's fine. But it is, in my opinion

Its probably in scope for IETF to figure out, but this might also be bigger
than network selection issue and handled separately. Anyway, lets focus
on mapping what the problem is, when that concludes we can think about
how to divide the work.

> one of the major things that has fallen through the cracks between IETF
> and IEEE. 

Agreed. Part of the reason for this is that the understanding of
various binding issues has only grown recently... and I think we
are still learning, as far it comes to IP vs. L2 issues.

--Jari