Christian Huitema escribió:
May I throw a dose of caution in this debate about host identifiers formats?
Many transition mechanisms rely on encoding information in the 64 bit host
identifier. This is of course a tempting design point, because it diminishes
the amount of state that servers have to keep.
Actually, i think it is not only the reduced state in the translation
device, but also the need for coordination between different services.
To put it more concretely, consider the case of the DNS64 and NAT64
(FWIW, DNS64 is a service that translates A RR into AAAA RR and the
NAT64 is the device that translates the IP packets.
for these two to work together, the IPv6 address contained in the
synthetic AAAA RR representing the IPv4 address, must be then treated by
the NAT64 device and the IPv4 address is extracted.
The interesting property is that the only thing that needs to be
synchronized between the DNS64 and the NAT64 is the prefix used to
represent IPv4 addresses in IPv6 address space.
If we give up embedding the IPv4 address in the IPv6 representation,
then we need to exhcnage the binding state of the IPv4 and its IPv6
representation between the dns64 and the nat64, and i think this would
add significant complexity and reduce the robustness of the overall solution
For example, Teredo encodes mapped port numbers and IPv4 addresses in the host
identifiers, so Teredo servers can be stateless. ISATAP uses a similar mechanism, and a
number of proposals follow the same design. But the gain, the reduction of server load,
comes at a cost. I am guilty, I did it with Teredo, but I still would like to encourage
designers of new protocols to consider the downside of these "structured
identifiers" encoding when they consider new approaches.
Structured host identifiers are incompatible with cryptographically generated
addresses, as used in SEND and proposed in SHIM6. We can argue that SEND is a
local protocol, and that the use of SEND can be decided on a subnet basis.
However, cryptographically binding addresses to public keys has huge potential,
not just inside subnets. Think about secure mobility, secure re-homing,
opportunistic IPSEC, and other kinds of end-to-end security. Standardizing
structured identifiers breaks that.
Maybe this can be addressed by having the Pref64 i.e. the prefix used to
make representations of IPv4 addresses in the IPv4 address space to be
shorter than 32 bits.
This would allow to have the Pref64+ IPv4 address shorter than 64 bits
and we can still embed crypto info in the last 64 bits as done with CGAs
Structured identifiers are not compatible with privacy address extensions.
Moreover, embedding addresses in identifiers discloses information that would
otherwise have remained hidden behind the NAT and the firewall. The IPv4
address encoded in the host identifier is passed to third parties, stored in
server logs. The third parties now have access to the local addresses used
inside the corporation. They can analyze subnet structure. At a minimum, this
should be a privacy concern.
The concerns about privacy can be mitigated by using algorithms that
scramble the bits of the IPv4 address around.
Combining embedded addresses with stateless servers opens the door to various
kind of denial of service attacks. We analyzed several such attacks in the
security analysis of Teredo, but the attacks are not specific to Teredo. The
attacks derive from the stateless nature of the transition mechanism. A
transition router, relay or gateway will receive a packet, extract the IPv4
next hop from the structured identifier, and blindly relay the packet towards
that next hop, whether that next hop participates in the transition scheme or
not. Based on that, attackers can build denial of service attacks, can hide
their tracks in reflection attacks, can spoof addresses.
but the deployment model for these transition tools seem to be different
than teredo, since they are expected to be locally managed, and not a
public server like 6to4 or teredo, so the translators are expected to
rely packets from their clients.
Regards, marcelo
The alternative is obviously to leave the identifier unstructured, and to
require transition servers to maintain the required mapping state. For example,
if I had to redesign Teredo today, I would require servers to maintain tables
of mapping between the Teredo hosts that they serve and the corresponding
mapped addresses. This would increase the cost of servers somewhat, but it
would improve security and privacy aspects of the protocol. The same could
easily be done for ISATAP, letting routers use a variation of non-multicast
neighbor discovery to enable traffic.
I would like to encourage designers of new transition schemes to study that
alternative. Leave the host identifier unstructured, or maybe use SEND as a
structure. Keep the transition state in a transition server. Use caching to
increase reliability and diminish server load.
-- Christian Huitema
_______________________________________________
Behave mailing list
beh...@ietf.org
https://www.ietf.org/mailman/listinfo/behave
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
