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

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 26 Mar 2004, Karim El-Malki (HF/EAB) wrote:
>  > > 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.

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]

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

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.

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

Right.  You among others objected to previous text proposals, so a new
one was coined up, trying to find a balance between different
proposals.
 
>  > 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 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..".

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

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

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

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.

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

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

> The implemented version is suitable for some important v6ops scenarios
> 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.

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

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

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