Re: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6ops-3gpp-analysis-09.txt]

[Brian E Carpenter <brc@zurich.ibm.com>]

Soliman,

Soliman Hesham wrote:
> 
> A comment on a couple of issues here.
> 
>  > OK, let's have a few.
>  >
>  > ISATAP uses a pseudo-interface (this is especially problematic if the
>  > implementation also has a 6to4 pseudo-interface, and one big reason
>  > why ISATAP should be avoided).  ISATAP accepts proto-41 packets from
>  > anyone.  ISATAP does direct tunneling between the nodes (even if they
>  > aren't in the same admin domain, if deployed as you propose).  ISATAP
>  > relies that the site has made appropriate protections at its
>  > perimeter, or else its security properties fall apart.  ISATAP was
>  > devised to be used inside a site, not across the sites.
> 
> => One answer to all of the above: The whole point of recommending
> a solution in specific scenarios is to assess the feasability
> of the solution to that particular deployment. None of the above
> is relevant for 3GPP:
>   - On this point to point link ingress filtering in the GGSN
>     stops address spoofing.
>   - It's always used in the same admin domain, logically, i.e.
>     as far as the IP layer can see.
>   - 6-to-4 is not recommended and should not be used by end
>     hosts. We discussed this several times and even Brian C
>     recommended against this a couple of years ago.

I certainly can see no scenario in which a 6to4 interface and
an ISATAP interface should be simultaneously active on the
same IPv4 interface. These should definitely be mutually
exclusive. And that should perhaps be stated in the document.

> 
> Given the above conditions, there is no security problems
> that we can see.
> 
>  > > So to start with IMO the above paragraph
>  > > should mention the existence of these implementations and their
>  > > interoperability since it is important for mobile
>  > operators/vendors to
>  > > know that there is something they can use. Now it
>  > basically says the
>  > > opposite i.e. no interoperability and wait for further work.
>  >
>  > I do not think that is appropriate at all.  If the WG has not made up
>  > its mind, WG document should not be pushing toward a solution which
>  > has known problems.  Better not nudge towards any particular
>  > direction.
> 
> => In other words make the doc vague and practically useles.
> This is the effect of not recommending anything.

I think the issue here is that ISATAP is a complicated solution
and not everybody is confident that it is good engineering to
recommend it. And of course STEP is too new.

> Regarding the WG opinion, I haven't seen anyone apart from
> you objecting to this. If I missed emails please point me
> to one. I asked several times to get WG concensus on this
> with no luck. What's the next step in the process ? How
> do I elevate this to see what the WG thinks ?

Have you polled people privately to find out who is intending
to productize ISATAP? In terms of a solid recommendation
to the 3GPP industry, that is more important than anything. What is
the status of ISATAP interoperability testing?

  Brian