> MT> In the case of mobility and multihoming, you might want a stable > MT> identifier on a per-packet basis which is independent of the routing > MT> layer. > > A number of folks clearly have in mind using the identifier in every packet. > My question is: Why is this needed? What requires putting the identifier in > every packet, rather than using it a occasional, special points of an > interaction, such as initial rendezvous?
I don't think an identifier is necessary in every packet. But I do think it makes sense to have a shim layer above IP which uses locators in the packets below (for IP's routing) and presents fixed length identifiers in the pseudo-headers passed to/from the upper layer protocols. The reason having identifiers in every packet isn't useful is that if you want to avoid facilitating redirection attacks of packet flows, then the receiver needs to verify at some level the relationship between locators and identifiers. The state (which can be soft-state created dynamically using a protocol similar to MAST) needed for this verification allows the receiver to recreate a packet with the same identifiers as what was sent by the peer ULP. Thus between the ULPs the shim provides a service which passes what looks like packets containing 128 bit identifiers, even though on the wire the packets have 128 bit locators. > Are we, perhaps, trying to add other functionality to the IP service, beyond > simply providing the current IP service, enhanced to support multihoming and > mobility? For example, are we trying to add extra levels of security to the > basic service, beyond simply making the use of multiple addresses carry the > same, minimal security functions present for current, single-address IP? I think the goal should be to not be any worse than the current IPv4 internet. In that Internet it is relatively easy for an attacker on the path between the two endpoints to redirect the packet flow - for instance it can use ARP spoofing like attacks to siphon off packets. But attackers that are not on this path can at most inject packets - with bogus source addresses in many cases. > The "security" associated with a current, bare-bones mono-address > host-to-host IP exchange is pretty darn small. I'd summarize it as simply > being the assertion that a datagram probably did come from the IP address in > the relevant field of the datagram. That's why MAST only tries to ensure an > equivalent degree of assurance that latter datagrams with different IP > addresses came from the same "system" that sent the first one. If you really > need stronger security, use IPSEC, TLS, or whatever. To analyze the security you have to look a more than just the IP layer. With TCP the initial sequence number makes it a tad bit harder (especially with non-guessable ISNs) for an off-path attacker to spoof a connection. While other protocols, such as DNS over UDP, require just guessing a 16 bit number in order to spoof a DNS response. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
