Re: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE]

[Pekka Savola <pekkas@netcore.fi>]

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.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings