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

[Fred Templin <osprey67@yahoo.com>]

I couldn't quite tell from your mesasge since you didn't state it;
was this a "WG chair hat on" message or a "bozo on the bus" message?

Fred
osprey67@yahoo.com


--- Pekka Savola <pekkas@netcore.fi> wrote:
> On Fri, 26 Mar 2004, Karim El-Malki (HF/EAB) wrote:
> >  > 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.
> > 
> > Just like an IPv6 host accepts IPv6 packets from anyone right?
> > By using appropriate security (incl. ingress filtering) you limit
> > the risks. But this is not a problem of ISATAP.
> 
> No, ISATAP opens a (semi-)trusted conduit, a virtual link, to everyone
> in the Internet (or everyone in the ISATAP site, if the border
> security is done properly).  Specifically, the ISATAP
> pseudo-interface, with its link local addresses and functionality
> using link-local addresses is placed at risk. This is not possible
> with just any IPv6 host.
> 
> This is completely different from any IPv6 host accepting IPv6
> packets.  To say it differently, a regular IPv6 host cannot receive
> packets with a link-local source address and TTL=255 from practically
> anyone out there, from completely untrusted source.  ISATAP allows --
> no, even stronger, requires! -- this.
> 
> (There are other problems with the ISATAP router spoofing as well, but 
> they are probably not as relevant compared to this.)
> 
> >  > 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.
> > 
> > And that's exactly what is proposed, it is always inside a site
> > from the IP viewpoint.
> 
> You do not understand the the concept of "administrative domain".  UEs 
> do not belong to the same AD as the 3GPP operator.
>  
> >  > I do not know which specific simplified subset of ISATAP you have in
> >  > mind, but these are fundamental issues with ISATAP as it is 
> >  > (and as it
> >  > always has been).  Some of these have been made worse (or new ones
> >  > introduced) along the lifetime of ISATAP, so depending on what's
> >  > implemented, it could be worse as well.
> > 
> > It has been implemented and used widely. You may claim that only a
> > subset was used and I would be happy to agree. Still that is a reason
> > for the ISATAP document to be modified to reflect what is deployed and
> > any limitations but not a reason to discard it. I am certainly in favour
> > of this and had already sent come comments to Fred Templin about this
> > to share with the authors.
> 
> It would help in this discussion if the specific features (and
> security protections) implemented and used was explicitly spelled out.
>  
> > By ignoring the reality of what is out there this will make it harder
> > for IPv6 to be deployed. Also you are just turning the tables since the
> > text you wanted in that spec is specifically pushing for STEP. So if there
> > is someone pushing for their solution which the WG has not adopted yet it's
> > not me unlike what you seem to be hinting. I would like ISATAP to be
> > given fair consideration, since it is anyway used today and a likely candidate
> > for more deployment in the short run. 
> 
> I fail to see what's unfair about the current text.  Moreover, no 
> objections were raised.
> 
> It just lists ISATAP as a proposal, mentions a few problems which have
> been raised about it, and describes a few alternatives in case these
> problems are considered to be a problem -- and says more work is
> needed.
> 
> > Creating an ISATAP vs. STEP competiton
> > as you are doing will just leave us with nothing to deploy since STEP is
> > too new.
> 
> So, are you saying, "we must get ISATAP, otherwise there is nothing we
> can deploy"?
> 
> FWIW, I certainly don't want to push for STEP.  There's work in
> progress to create a more unified tunnel server solution.  But IMHO
> ISATAP seems to have way too many drawbacks to go for it blindfolded.
> And don't say this comes as a late surprise.  I think I've been
> complaining about this at least a year or two now, but folks don't
> seem to care or don't seem to have sufficient security expertise to
> even understand the problems.
> 
> >  > Read closer about non-interoperability: it says basically that if we
> >  > wanted to "simplify" or secure ISATAP considerably, that would likely
> >  > require non-interoperable changes to the spec.  It is not trying to
> >  > say that current ISATAP implementations are non-interoperable.
> > 
> > Since current interoperable ISATAP implementations are already a
> > "simplified" version your logic doesn't make sense.
> 
> Then they quite likely aren't yet what was referred to with the
> "simplified" reference in draft-ietf-v6ops-3gpp-analysis-09.
> 
> I.e., such simplified version could be e.g. a variant which would not
> include direct tunneling between ISATAP nodes at all.  This would not 
> be suitable in some other contexts, though.
> 
> >  > > The paragraph above also talks about ISATAP complexity and 
> >  > this does
> >  > > not match the experience with the deployed base. We're 
> >  > talking about
> >  > > supporting RA/RS over a tunnel interface and that doesn't seem like
> >  > > something complex. 
> >  > 
> >  > It has much more to it than just RA/RS over a tunnel interface.
> > 
> > Again, it says deployed base.
> 
> Direct tunneling between ISATAP nodes in the same ISATAP site is in
> the deployed base, right?  Thought so.
> 
> >  > I don't think you understand the issues that come into play when you 
> >  > deploy something to be used across administrative domains.  The 
> >  > interface between domains must be carefully analyzed.  It 
> >  > helps a lot 
> >  > if the interface is simple and easy to understand (IMHO which ISATAP 
> >  > isn't).
> > 
> > Actually I think your logic does not reflect at all how a 3gpp mobile
> > network works. Once again, there is no crossing of administrative domains
> > in the way you mean it.
> 
> Administrative domain as a concept has very little to do with the
> technique used in the network.  I.e., it still holds.
> 
> >  > It is one thing to say that the 3GPP operator has identified the user
> >  > (whether using regular or pre-paid SIM or whatever) -- and
> >  > consequently everything any user does to the operator, the 
> >  > Internet or
> >  > the user would be magically trusted -- and another to consider what
> >  > the user is able to believe.
> >  > That is, 1) can the user trust 
> >  > the other
> >  > 3GPP users who are doing direct tunneling to it, possibly injecting
> >  > malicious packets (which they wouldn't be able to do, unless 
> >  > there was
> >  > ISATAP),
> > 
> > This has nothing to do with ISATAP. With native IPv6 or IPv4 users can
> > just send each other packets and these packets are in no way less likely
> > to be malicious than tunnelled packets.
> 
> Wrong.  See the link-local threat.
>  
> >  or 2) can the user trust that the 3GPP operator has secured
> >  > *all* of its borders properly, so that either other users, or anyone
> >  > in the internet could not inject maliscious packets to the user.  L2
> >  > identification helps with none of this.
> > 
> > It just has to do ingress filtering in the GGSN which from what I know
> > is default. So you should assume it is default and if anything explicitly
> > state this as an assumption/requirement.
> 
> Again, this doesn't help against the link-local threat.
>  
> >  > All of these issues are much simpler with something resembling
> >  > configured tunneling, which is why it's preferable.  STEP 
> >  > and the like
> >  > are just extensions of that model to make the tunnel easier to
> >  > configure, but the security properties are still the same.
> > 
> > I am not saying work should stop on STEP. What I am saying is that
> > ISATAP is already being used and has good reasons for that. 
> 
> And a large number of reasons why this is an incredibly bad idea.
> 
> Tell me why again the IETF should be advocating bad practice, just
> because someone didn't understand the consequences and needed
> something to deploy -- and the first solution that came across seemed
> to fit?
> 
> > So the
> > draft should be quickly adapted to reflect what is deployed and
> > moved on. That will give us a solution which we can use. Otherwise
> > we will continue with this standstill situation.
> 
> Standstill may be better than bad solution.  It might help us to get
> to a good solution.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
>