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

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Fri, 26 Mar 2004 20:43:02 +0100

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Mar 2004 23:05:27 +0200 (EET)

> previous discussions. Host-to-router is what is used in the deployments

Note that this is in conflict with a lot of deployments in (non-3GPP) 
cases, e.g., inside certain enterprises.  There may be a lot of 
pushback for making that change. (Which is why I've taken this to be 
an integral feature of ISATAP.)

[cutting down some quotes which didn't seem relevant anymore]

> addresses those features.

Obviously.

However, as noted above, I see an inevitably conflict of interests 
down the road if one removes host-to-host part of ISATAP.  

So, the question is whether one could get consensus for such a change.

I mean, as this is a non-trivial change, I don't think one can go
around asking for, "do we want to go ahead with ISATAP?" and then
modify it like this.  We have to have a stronger strawman proposal
(and some form of acceptance) in the table.  Like, "this is
ISATAP-DirectTunneling [draft1], this is ISATAP-HostToRouterOnly
[draft2] .. is one of these the way we want to go?"

To be frank, if you look at the minimized ISATAP protocol (only
host-to-router part), it's practically quite similar to what STEP (in
Ad-hoc) is doing, except instead of the router being able to give you
a /64 (or more), the client calculates a /128 for itself (simplifying
one part of the process).  So, I'm not sure whether it's worth taking
ISATAP that road (though it may be an interesting exercise to see how
it'd look like), as it seems to be fundamentally different from the
original ISATAP design.

> time but these issues aren't new.

Right.  You among others objected to previous text proposals, so a new
one was coined up, trying to find a balance between different
proposals.
 
> this doc is about) which we don't seem to have an agreement on.

It does not say ISATAP has problems; it says "issues have been raised
about it".  It leaves the interpretation whether those issues are
relevant or not to the reader.  It specifically didn't say "we have
consensus that ISATAP has these and these problems..".

> with it. So I read it as saying that STEP is the way to go.

No significant issues have been raised about it, so it'd be difficult
to mention those :-).

> all the time since you understand the problems?

Agreeing doesn't hurt of course ;-) .. but it isn't necessary.  

I'm trying to get to the point where people voicing opinions are
making *informed* decisions.  Without sharing understanding of the
issues (which apparently hasn't been too succesful, probably partially
due to my fault for not documenting them more precisely, e.g. in an
Internet-Draft) it's difficult to argue whether there is agreement
whether they are significant issues or not (which hasn't really
happened so far).

Read: I'm personally strongly against making uninformed decisions.

> The text just says simplified, and we can take that to mean anything.

Which is why it also said, "probably non-interoperable". :)

> so it is worth spending time on it IMO.

The implemented version(s), at least about three of them which I'm
aware of, contain the host-to-host interactions as well.

> what I wrote above is bad practice.

I've been trying... ;-)

Why do you think I've been trying to preach against this for a long
time, wasting a lot of time in the process?  Hint: I don't derive
pleasure from disagreeing with people ;-).

It's because I *do* think it *is* a bad idea, and could be harmful
thing to recommend.  It's unfortunate that some have taken it and
deployed it (in scenarios where it's not IMHO suitable)  already, and
some others are considering it: I'd hope these discussions would have
taken place 3 years ago.  But even more unfortunate would be saying
"OK, now that a couple of players have deployed it or piloted that,
because they went there on their own not knowing (or believing) the
dangers, we should follow suit and dive in the shallow water ourselves
as well."  That does not seem like a good idea at all.

It might be that in the end we could decide that, OK, with
sufficiently strong warnings, good text in the document, added
security checks, or whatever, the protocol might go forward in some
form and be recommended ... but THAT should have to be done in an
informed fashion, documenting/being aware of the concerned issues, not
like it seems to have been pushed until now.
 
> I strongly disagree with this approach. I'd actually like to see IPv6

If you note, I'd rather not wait for something good to happen.  Some
alternatives have been proposed (just as a proof-of-concept) when I
got furstrated when it wasn't apparent that alternative solutions
could provide the same features with less pain.  Some new
proposals/integrated protocols are being worked.  This is more of a
question of the will to go forward with eyes open or not.

....

Even if this thread may not have been the most productive one at
start, based on this exchange I'm hoping that we're moving towards
better understanding .. and will likely be able to solve (or at least
gain understanding) of these very difficult issues easier in the short
term.

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