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

[Fred Templin <ftemplin@iprg.nokia.com>]

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.

  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.

  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, and the AAAA records
    are host routes that use the link-local address as the IPv6 next-hop.
    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. 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.

  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.

Was there anything else, or does this cover it?

Fred
ftemplin@iprg.nokia.com

Pekka Savola wrote:

>On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote:
>
>
>>OK. There are 3gpp specific mechanisms for this like ggsn
>>spoofing protection. But these are generic issues which are
>>not specific to ISATAP.
>>
>>
>
>Certainly, but the existance (or not) and use (or not) of these
>mechanisms certainly affect the requirements for the solutions we
>have.
>
>
>
>> > As it should be obvious, security mechanisms used and assumptions
>> > implied when devising a solution to the enterprise network are very
>> > probably not adequate for ISP/3GPP scenarios with a different set of
>> > requirements.
>> >
>> > Hence, I have always given significant pushback for re-using the
>> > ISATAP model outside of its (original?) scope, the enterprise
>> > networks.
>>
>>You have talked above about generic security issues which exist
>>independently of ISATAP. Even if you don't use ISATAP you still
>>have those issues and I think many are addressed in 3gpp. So how
>>can you come to the conclusion to push-back on ISATAP?
>>
>>
>
>The point is that we know the security issues (or lack thereof) in the
>simple mechanisms such as configured tunnels.
>
>We have not done the rounds of a full analysis of more complex
>techniques such as ISATAP.
>
>Until that is done, I do not believe it is appropriate to consider
>anything more complicated seriously.
>
>
>
>>We've already discussed the ISATAP security issues and I don't
>>see the problem when using it in the 3gpp network. Plus it
>>is only an optional mechanism!
>>
>>
>
>It has been "discussed" (to some definition of "discussed"), but not
>properly analyzed, AFAICS.
>
>
>
>>We must create appropriate solutions to solve problems and not
>>ignore them or generate new ones (like the configured tunnel
>>proposal), otherwise quite naturally people will go off and solve it
>>their own way. I think people want to solve problems they don't just
>>like to do things.
>>
>>
>
>This is exactly the reason why I'd like to see more discussion what to
>do (or not to do), so that people don't need to make their own
>solutions if they don't need to.
>
>
>
>>Careful reviewing is important but specs being
>>discussed for years when they are implemented and out in commercial
>>products just demonstrates that there is something wrong with the
>>way we are handling things.
>>
>>
>
>So as long as a spec has not been properly analyzed, but is already
>implemented or to a degree deployed, we should forget about the warts
>in the specs?
>
>Sorry, I don't subscribe to that belief.  Maybe the analysis should
>have happened sooner, or we should have finished the framework to that
>analysis (scenarios work?) sooner?
>
>
>