On Tue, 18 Nov 2003, Fred Templin wrote:
Just trying to summarize and respond to what I perceive as Pekka's
outstanding concerns:
1) The ISATAP host not being trusted by the 3GPP network:
We have the 3GPP PDP context which provides authenticated
L2 access. Pekka seems to think this isn't good enough to ensure
that the node can be trusted by the operator, but this is exactly
the same case whether/not ISATAP is used. This is therefore
not an ISATAP issue.
The main case here was to make the difference between the enterprise
deployment and 3GPP environment; i.e., what is built for enterprise,
is not typically just a plug-in for 3GPP. There is certainly nothing
in L2 (or lower) authentication in 3GPP which should make the operator
to trust the user more -- the point is just that the mechanisms used
have to be able to be designed to the situation where no such trust
exists.
Whether or not ISATAP is designed for being used between untrusted
peers is an open issue.
2) ISATAP including mechanisms other than for host<->router
interactions:
- It is true that mechanisms are provided that allow nodes with
the same prefix to talk directly w/o going through an ISATAP
router when ISATAP addresses are used. But, this mechanism
probably won't be used much (if at all) in practice. Instead,
the vast majority of interactions will be host<->router.
How come it would not be used?
It's still in the spec, and has to be implemented, like a dozen other
features which are unnecessary for a simple host-router tunneling.
3) ISATAP nodes not being trusted by other ISATAP nodes:
- ISATAP routers are identified by their FQDN which resolves
to a set of AAAA and A RR's. The A record is used to create the
ISATAP link-local address of the router,
Yes..
and the AAAA records
are host routes that use the link-local address as the IPv6 next-hop.
Not in -16 spec.
The initail RS causes the router to do a reverse-DNS lookup for
the IPv6 source address, which returns a list of AAAA and A records
for the initiating host.
Not in -16 spec.
The returned RA includes routes which are
checked against the AAAA and A records the host learned from the
DNS. If the routes match what was learned from the DNS, we have
mutual authentication since both ISATAP nodes trust the information
in the DNS and the end-to-end trust issue is resolved.
A part of this is true.
You probably have some other ISATAP in mind that what's documented in
draft-ietf-ngtrans-isatap-16.txt.
Even if these were implemented like you say, one could argue whether
DNS lookups (forward & reverse) is the right way to do this.
But, the main concerns about ISATAP wrt. to security are:
- ISATAP is too much of a moving target. It changes significantly
between about each revision. Because it's not stable, it's difficult
to review its properties and how they evolve over time. (Naturally,
the ISATAP implementations that currently exist have very little to do
with draft-ietf-ngtrans-isatap-16.txt; for example, Cisco implements
isatap-03 spec AFAIK).
Actually the spec could be improved a lot to be more clear, e.g., it
doesn't properly describe what happens to IPv6 packets in an ISATAP
node in when considering where to forward them (e.g., does the
pseudo-interface have a global /64 on-link ISATAP prefix and
everything else goes through default routers or what). I.e., maybe a
high-view decision tree "if I'm an ISATAP node and I have an IPv6
packet I want to send, this is how I'll do it" could clarify this.
- we need to analyze the security from the points of view if IPv4
spoofing is possible (or not) and if IPv6 spoofing is possible (or
not) [if v6 was deployed] within the 3GPP network. There are likely
to be some differences to be found here.
- the biggest problem of ISATAP will probably come from the fact that
all IPv6 nodes in an ISATAP site ("all of 3GPP network") are
considered to be IPv6-wise "on-link" with each other. This implies
being on-link with every other node; this has a huge number of
possible threats (SEND). I don't know about you, but this scares me
shitless. Worse than that, this is actually a design feature of
ISATAP, not just something that happens to be possible if the ISP is
lazy and doesn't do the easiest form of IPv4 filtering. (On the other
hand, with configured tunneling, you're only on-link with the 3GPP
operator's router, unless someone manages to spoof it.)
- you mandate the use of IPsec AH for SLLA/TLLA options with ISATAP
in the current spec. Are you aware that this probably requires
changes to the encapsulating RFC2461 stacks as well, and is probably
difficult to deploy in the first place?
(this is not trying to be a conclusive list of the problems, but most
stem from the fact that ISATAP nodes are on-link with each other.)
4) Crossing administrative boundaries:
- If we have a NOT (Network Organizational Translator) in the path,
the ISATAP proto41 packets will undergo translation and cross an
organizational boundary. But, we have the mutual authentication in
3) to support the end-to-end trust. Some communications SHOULD NOT
cross organizational boundaries (e.g., print services, network
filesystem, etc.) and these will use IPv6 addresses with
appropriate scoping to avoid leakage.
I'm not sure if I understand your point. There is no NAT in the path
in the case of ISATAP. I do not understand what you mean to say about
mutual authentication, as ISATAP nodes can communicate directly,
being on-link, IPv6-wise.