Hi Fred,

> Hence, I would like to use SeND to exchange RFC 3401 addresses, and
> have H1 do so with any system that it wants to talk with/through on
> its local LAN for any address relevant to the association prior to
> other L3 exchanges. Host-to-host within the LAN, I would expect that
> to be limited to link-local addresses as it is now (one could also
> send everything through the router, but that solution doesn't help
> LANs that have no router, and has limitations on very busy LANs). With
> any system originating SeND-authenticated Router Advertisements, I
> would expect that it would do so for any address it wants to use off-LAN.

This is an interesting case.

So SEND gives you secure mapping of IP to L2 addresses, as
well as address ownership.

SEND currently does nothing for actual traffic packets, so presumably
you are thinking of maintaining some state or performing some
extra verification tasks at the router. This would allow the SEND-
secured mapping and ownership to be used for a packet forwarding
decision.

It would probably be a bad idea for the router to listen to all
NA/NS traffic. So I'm not sure we want to base the state
on that.

Are you thinking of the router making an extra SEND
operation to verify ownership when it for the first time
sees a packet? It could send an NS and verify the resulting
NA. And use this for the forwarding decision.

This would not, however, prevent someone who can forge
L2 source addresses from claiming that an IP packet came
from a host. So for a full solution I guess you would also
need to enforce L2 source addresses, either through
switch configuration or L2 security.

> If I'm off in the weeds, I'm willing to be told as much. In the case,
> though, I'm very concerned.

I don't think you are off in the weeds -- this is an interesting
direction for the SAVA problem. But more work is definitely
needed.

Jari



_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area

Reply via email to