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

["Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>]

 > > 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.

It is good that you bring this up. The host-to-router model is the only
one we have ever talked about using. It is not difficult to have only
a default route to the ISATAP router and only accept tunnelled packets from
it. I am in favour of the spec being updated in this sense as from
previous discussions. Host-to-router is what is used in the deployments
I know about.

 > >  > 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 don't think we should be wasting much time on this point since
we should focus on how things work today. When a terminal is
authenticated it is allowed access to a certain basic set of services
and this can be one of them.

 >  
 > >  > 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.

This is mostly something for the ISATAP authors IMO.
We can then discuss based on a new version of the draft that
addresses those features.

 >  
 > > 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.

I remember objecting several times on the admin boundary crossing
issue and the protocol's complexity. I may have missed the last
time but these issues aren't new.

 > 
 > 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.

It says that ISATAP has some problems (in 3ggp nets which is what
this doc is about) which we don't seem to have an agreement on.
It also says that STEP is an alternative and doesn't mention issues
with it. So I read it as saying that STEP is the way to go.

 > > 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"?

It's already out there anyway. So yes I do say that, given that I do
not see the great problems you see. If the spec is modified according
to what we talked about above, and Fred's message seems to hint that
this may be the direction, then it would certainly help deployment IMO.
And I'm not thinking only about the mobile field of course.

 > 
 > 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.

Maybe people don't care because you expect them to agree with you
all the time since you 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 text just says simplified, and we can take that to mean anything.
The implemented version is suitable for some important v6ops scenarios
so it is worth spending time on it IMO.

 > 
 > >  > > 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 already commented on that above.

 > 
 > >  > 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.

I am talking about how a mobile network works and don't know
what to answer when you reply with a concept.

 > 
 > >  > 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.

See the host-to-router discussion that we've been having over and
over again. I fully agree that building only on the host-to-router
model (i.e. default route and only accept packets from the router)
is the right way ahead. Ingress filtering is assumed as default as
I said before.

 >  
 > >  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.

It does if we ensure that the host-to-router model is used.
Other general threats would be in the SEND area.

 >  
 > >  > 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?

I guess I would be that someone you talk about, well enlighten us
ignorants then! Seriously, I don't think you have grounds to claim
what I wrote above is bad practice.

 > 
 > > 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.

This attitude is what has helped get v6ops to a standstill.
It's true that we could just keep on following your recommendation to push
back on everything and wait for something good to happen...but obviously
I strongly disagree with this approach. I'd actually like to see IPv6
deployed.

/Karim

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.