On Jun 5, 2007, at 3:53 AM, marcelo bagnulo braun wrote:
do you think there are some features that SeND should support to
deal with this type of cases independently of the actual SAVA
solution adopted or do you think that the the changes required to
SeND heavily depend on the actual final SAVA solution? I mean, if
it is the first case, it would be interesting to work on this at
this stage, but if it is the second option probably we should wait
till the SAVA solution is more defined?
The solution Tsinghua has prototyped is a form of CGA, AFAIK does not
use SeND, and is focused not on system identity but on user identity.
I have a number of thoughts that I have expressed to them and won't
burden this forum with.
The proposal that I have run past them (and will one day get around
to posting as an I-D - it's written now and is in review) focuses not
on identifying users, but on verifying that the system that
originated a datagram using a given source address can be expected to
receive the datagram sent in reply. It applies to both IPv4 and IPv6
technology, and mostly uses existing technologies, including both
uRPF and approaches suited to the local LAN. On the local LAN, it
depends on the association of the source address with something else
- an L2 address or physical port. One weakness of current technology
is that it also depends on having the address assigned to the system
by some outside entity, while most IPv6 systems use SAA, potentially
with some form of privacy addressing. Another is that this assignment
must be visible in some sense to each party that needs to verify the
address pairing, which in a campus wireless LAN has obvious negative
implications. I would far rather enable the use of SAA and privacy
addressing and still be able to associate an L2 address with the set
of L3 addresses a system uses, and do so in a manner that scales to a
campus LAN with thousands of systems on it.
In theory, it seems to me that SeND should be usable for the purpose.
ND has many of the same lack-of-security issues that ARP does, and
also has a chicken/egg problem; in the following sketch, if H1 opens
a connection to H2 using a privacy address calculated on the LAN, R1
does not necessarily learn of the association of H1's MAC and IPv6
addresses until it sees the reply from H2 and sends a Solicitation.
But if it is refusing to forward datagrams for which that association
is not known and therefore not verifiable, it will not send the
datagram H1->H2 to open the session.
+--+ | | +--+
|H1+-+ +-+H2|
+--+ | | +--+
| +--+ +--+ |
+-+R1+-------+R2+-+
| +--+ +--+ |
oops.
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.
If I'm off in the weeds, I'm willing to be told as much. In the case,
though, I'm very concerned.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
