Subject: RE: ISATAP and admin/IP domains [RE: 3gpp-analysis: Recommendatio n on tunneling in the UE]

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Tue, 18 Nov 2003 19:25:54 +0100

> > I don't understand what you mean? The user gets charged and is able
 > > to access services (e.g. internet access). That's the 3gpp 
 > model and
 > > ISATAP can be just one of those services.
 > 
 > Let me try to clarify, as the differences in security properties of 
 > different scenarios are clearly not clear.
 > 
 > My home xDSL system gets charged as well, and the ISP provides me 
 > services as well.
 > 
 > That doesn't mean the ISP trusts me to "behave well" in 
 > their network.  
 > E.g., I can spoof my address, I can send specially crafted packets, I
 > can try to confuse their router with OSPF packets if they haven't
 > disabled the interface, I can harass my neighbor, etc.etc. -- to the
 > ISP (and other users), I'm a "hostile user".

OK. There are 3gpp specific mechanisms for this like ggsn
spoofing protection. But these are generic issues which are
not specific to ISATAP.

 > 
 > Much the same with 3GPP, actually more, because you don't 
 > have to have 
 > a contract or details where you can be traced, because you can use 
 > anonymous SIMs and similar.
 > 
 > In a similar fashion, you cannot trust other users, because 
 > you cannot 
 > trust that the ISP is ensuring that the users cannot harm you (even 
 > if that was somehow possible).
 > 
 > On the other hand, within an enterprise network, or at least 
 > a branch 
 > of the enterprise network, typically the assumptions are entirely 
 > different: you have to trust the users at least to some degree.  You 
 > have contracts etc. with them.  While some host may be acting weird 
 > for some reason, the users are not typically intentionally 
 > malicious.

Not sure I totally agree on this but I see the point.

 > 
 > So...
 > 
 > As it should be obvious, security mechanisms used and assumptions
 > implied when devising a solution to the enterprise network are very
 > probably not adequate for ISP/3GPP scenarios with a different set of
 > requirements.
 > 
 > Hence, I have always given significant pushback for re-using the 
 > ISATAP model outside of its (original?) scope, the enterprise 
 > networks.

You have talked above about generic security issues which exist
independently of ISATAP. Even if you don't use ISATAP you still
have those issues and I think many are addressed in 3gpp. So how
can you come to the conclusion to push-back on ISATAP?
We've already discussed the ISATAP security issues and I don't
see the problem when using it in the 3gpp network. Plus it
is only an optional mechanism!

 > > But please take note that there are people on this list 
 > who would like
 > > to stop discussing and start finishing off those specs now 
 > pending for
 > > years.
 > 
 > I'm sure that there are people who would like to do that.  On the
 > other hand, that's exactly what we should not do, as even the
 > differences in security properties are not clear enough.
 > 
 > We must do what we must do, not necessarily what people would like to
 > do.

We must create appropriate solutions to solve problems and not ignore
them or generate new ones (like the configured tunnel proposal), otherwise
quite naturally people will go off and solve it their own way. I think
people want to solve problems they don't just like to do things. Careful
reviewing is important but specs being discussed for years when they are
implemented and out in commercial products just demonstrates that there is
something wrong with the way we are handling things.

/Karim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 21:34:57 +0200 (EET)

> spoofing protection. But these are generic issues which are

Certainly, but the existance (or not) and use (or not) of these 
mechanisms certainly affect the requirements for the solutions we 
have.

> can you come to the conclusion to push-back on ISATAP?

The point is that we know the security issues (or lack thereof) in the 
simple mechanisms such as configured tunnels.

We have not done the rounds of a full analysis of more complex
techniques such as ISATAP.

Until that is done, I do not believe it is appropriate to consider 
anything more complicated seriously.

> is only an optional mechanism!

It has been "discussed" (to some definition of "discussed"), but not 
properly analyzed, AFAICS.

> We must create appropriate solutions to solve problems and not
> ignore them or generate new ones (like the configured tunnel
> proposal), otherwise quite naturally people will go off and solve it
> their own way. I think people want to solve problems they don't just
> like to do things. 

This is exactly the reason why I'd like to see more discussion what to 
do (or not to do), so that people don't need to make their own 
solutions if they don't need to.

> Careful reviewing is important but specs being
> discussed for years when they are implemented and out in commercial
> products just demonstrates that there is something wrong with the
> way we are handling things.

So as long as a spec has not been properly analyzed, but is already 
implemented or to a degree deployed, we should forget about the warts 
in the specs?

Sorry, I don't subscribe to that belief.  Maybe the analysis should 
have happened sooner, or we should have finished the framework to that 
analysis (scenarios work?) sooner?

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

---

From: Fred Templin <[email-masked]>
Date: Tue, 18 Nov 2003 13:59:21 -0800

Just trying to summarize and respond to what I perceive as Pekka's
outstanding concerns:

   1) The ISATAP host not being trusted by the 3GPP network:
     We have the 3GPP PDP context which provides authenticated
     L2 access. Pekka seems to think this isn't good enough to ensure
     that the node can be trusted by the operator, but this is exactly
     the same case whether/not ISATAP is used. This is therefore
     not an ISATAP issue.

   2) ISATAP including mechanisms other than for host<->router
     interactions:
     - It is true that mechanisms are provided that allow nodes with
     the same prefix to talk directly w/o going through an ISATAP
     router when ISATAP addresses are used. But, this mechanism
     probably won't be used much (if at all) in practice. Instead,
     the vast majority of interactions will be host<->router.

   3) ISATAP nodes not being trusted by other ISATAP nodes:
     -  ISATAP routers are identified by their FQDN which resolves
     to a set of AAAA and A RR's. The A record is used to create the
     ISATAP link-local address of the router, and the AAAA records
     are host routes that use the link-local address as the IPv6 next-hop.
     The initail RS causes the router to do a reverse-DNS lookup for
     the IPv6 source address, which returns a list of AAAA and A records
     for the initiating host. The returned RA includes routes which are
     checked against the AAAA and A records the host learned from the
     DNS. If the routes match what was learned from the DNS, we have
     mutual authentication since both ISATAP nodes trust the information
     in the DNS and the end-to-end trust issue is resolved.

   4) Crossing administrative boundaries:
     - If we have a NOT (Network Organizational Translator) in the path,
     the ISATAP proto41 packets will undergo translation and cross an
     organizational boundary. But, we have the mutual authentication in
     3) to support the end-to-end trust. Some communications SHOULD NOT
     cross organizational boundaries (e.g., print services, network
     filesystem, etc.) and these will use IPv6 addresses with
     appropriate scoping to avoid leakage.

Was there anything else, or does this cover it?

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Nov 2003 13:48:03 +0200 (EET)

>      the same case whether/not ISATAP is used. This is therefore

The main case here was to make the difference between the enterprise 
deployment and 3GPP environment; i.e., what is built for enterprise, 
is not typically just a plug-in for 3GPP.  There is certainly nothing 
in L2 (or lower) authentication in 3GPP which should make the operator 
to trust the user more -- the point is just that the mechanisms used 
have to be able to be designed to the situation where no such trust 
exists.

Whether or not ISATAP is designed for being used between untrusted 
peers is an open issue.

>      the vast majority of interactions will be host<->router.

How come it would not be used?

It's still in the spec, and has to be implemented, like a dozen other
features which are unnecessary for a simple host-router tunneling.
 
>      ISATAP link-local address of the router, 

Yes..

>      and the AAAA records

Not in -16 spec.

>      for the initiating host. 

Not in -16 spec.

> The returned RA includes routes which are

A part of this is true.

You probably have some other ISATAP in mind that what's documented in
draft-ietf-ngtrans-isatap-16.txt.

Even if these were implemented like you say, one could argue whether 
DNS lookups (forward & reverse) is the right way to do this.

But, the main concerns about ISATAP wrt. to security are:

 - ISATAP is too much of a moving target.  It changes significantly
between about each revision.  Because it's not stable, it's difficult
to review its properties and how they evolve over time. (Naturally,
the ISATAP implementations that currently exist have very little to do
with draft-ietf-ngtrans-isatap-16.txt; for example, Cisco implements
isatap-03 spec AFAIK).

Actually the spec could be improved a lot to be more clear, e.g., it
doesn't properly describe what happens to IPv6 packets in an ISATAP
node in when considering where to forward them (e.g., does the
pseudo-interface have a global /64 on-link ISATAP prefix and
everything else goes through default routers or what).  I.e., maybe a
high-view decision tree "if I'm an ISATAP node and I have an IPv6
packet I want to send, this is how I'll do it" could clarify this.

 - we need to analyze the security from the points of view if IPv4 
spoofing is possible (or not) and if IPv6 spoofing is possible (or 
not) [if v6 was deployed] within the 3GPP network.  There are likely 
to be some differences to be found here.

 - the biggest problem of ISATAP will probably come from the fact that
all IPv6 nodes in an ISATAP site ("all of 3GPP network") are
considered to be IPv6-wise "on-link" with each other.  This implies
being on-link with every other node; this has a huge number of
possible threats (SEND).  I don't know about you, but this scares me
shitless.  Worse than that, this is actually a design feature of
ISATAP, not just something that happens to be possible if the ISP is
lazy and doesn't do the easiest form of IPv4 filtering. (On the other
hand, with configured tunneling, you're only on-link with the 3GPP
operator's router, unless someone manages to spoof it.)

 - you mandate the use of IPsec AH for SLLA/TLLA options with ISATAP 
in the current spec.  Are you aware that this probably requires 
changes to the encapsulating RFC2461 stacks as well, and is probably 
difficult to deploy in the first place?

(this is not trying to be a conclusive list of the problems, but most
stem from the fact that ISATAP nodes are on-link with each other.)

>      appropriate scoping to avoid leakage.

I'm not sure if I understand your point.  There is no NAT in the path
in the case of ISATAP.  I do not understand what you mean to say about
mutual authentication, as ISATAP nodes can communicate directly, 
being on-link, IPv6-wise.

---

From: Fred Templin <[email-masked]>
Date: Wed, 19 Nov 2003 09:52:10 -0800

Pekka,

I don't agree that the items you are citing as "not in draft-16"
actually need to be specified there.

Also, as to your assertion that ISATAP is a "moving target",
the best way to address that would be to either publish it as
an RFC now or make it as a v6ops wg item. I prefer the
former; we have seen recently how easily RFCs can be
(bis)'d so there is no reason to believe that publishing now
would amount to casting things in stone.

Thanks - Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Nov 2003 20:41:26 +0200 (EET)

> actually need to be specified there.

If you want to say ISATAP does (foo), it has to be specified to do 
(foo).  If it isn't specified, it ain't there..
 
> would amount to casting things in stone.

I have an entirely different opinion (about publishing as RFC).  
There is little use documenting a snapshot of a "moving target".  
That'd clearly show that the moving target has not been specified well
enough, had its applicability considered at enough length, etc. -- 
because otherwise it would not be moving any more.

On the other hand, when a mechanism does not change substantially any
more, it's either because (1) people lost interest, or (2) the
mechanism is clear enough (from every angle) that there is no more
NEED to substantially refine it further.

When there are still substantial issues to be ironed out, about the 
only way to generate a revision of the spec would be creating a 
non-interoperable new version using a new suffix.  I'm not sure if 
that'd be warranted either.

---

From: Fred Templin <[email-masked]>
Date: Wed, 19 Nov 2003 11:05:22 -0800

>(foo).  If it isn't specified, it ain't there..

That's not what I'm saying; ISATAP is an IPv6-over-(foo) document
whose sole purpose is to specify the operation of IPv6 neighbor
discovery over a particular link type. As such, it doesn't have any
business specifying things that might be happening further up the
stack. ISATAP is a substrate on top of which other mechanisms
might be layered, but that does NOT mean specifications for
those other mechanisms belong in the ISATAP spec.

>because otherwise it would not be moving any more.

Actually, I should have more strongly disagreed with your assertion;
ISATAP is NOT a moving target. ISATAP is stabilized, and I have
not received any input to the contrary.

>NEED to substantially refine it further.

(2) above best describes the case for ISATAP as I understand it.

>that'd be warranted either.

Not warranted in my view as there are not still substantial issues
to be ironed out to my knowlege.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Nov 2003 14:52:59 +0200 (EET)

Whether or not ISATAP is stable or not is beside the original point, 
so I don't think I'll continue this thread..

On Wed, 19 Nov 2003, Fred Templin wrote:
> discovery over a particular link type. 

Right..

> As such, it doesn't have any

That's fine, just don't describe that as ISATAP behaviour then (as 
you did, in the original thread, a few messages back).

> not received any input to the contrary.

I have to disagree here.

Let's have a look at when different versions of the ISATAP spec were 
published:

draft-templin-ngtrans-v6v4compat-00.txt: Mar 2000
draft-templin-ngtrans-v6v4compat-01.txt: Sep 2000
draft-ietf-ngtrans-isatap-00.txt: Mar 2001
draft-ietf-ngtrans-isatap-01.txt: May 2001
draft-ietf-ngtrans-isatap-02.txt: Nov 2001
draft-ietf-ngtrans-isatap-03.txt: Jan 2002
draft-ietf-ngtrans-isatap-04.txt: Apr 2002
                                                                                
<ngtrans replaced by v6ops on Aug 2002>
                                                                                
draft-ietf-ngtrans-isatap-05.txt: Oct 2002
draft-ietf-ngtrans-isatap-06.txt: Oct 2002
draft-ietf-ngtrans-isatap-07.txt: Dec 2002
draft-ietf-ngtrans-isatap-08.txt: Dec 2002
draft-ietf-ngtrans-isatap-09.txt: Dec 2002
draft-ietf-ngtrans-isatap-10.txt: Jan 2003
draft-ietf-ngtrans-isatap-11.txt: Jan 2003
draft-ietf-ngtrans-isatap-12.txt: Jan 2003
draft-ietf-ngtrans-isatap-13.txt: Mar 2003
draft-ietf-ngtrans-isatap-14.txt: Aug 2003
draft-ietf-ngtrans-isatap-15.txt: Sep 2003
draft-ietf-ngtrans-isatap-16.txt: Oct 2003

.. seems to have been very much of a moving target to me :-).  Of
course, you'd argue that it *has* been a moving target, but now is
frozen.  Looking at the spec (there are a large number of things to
fix) and its past change history does not convince me.

(But of course, this is a fundamental problem caused by the fact that
there is no clear goal for ISATAP, no clear objective; it has tried to
be "little everything for everybody"; when new uses for it have come
up, it has been modified to fit.  If there was a clear goal where to
apply ISATAP and which direction to develop it, I guess the need for
fundamental changes would have gone down a long time ago.)
 
> (2) above best describes the case for ISATAP as I understand it.

I don't agree.

---

From: Fred Templin <[email-masked]>
Date: Thu, 20 Nov 2003 09:37:00 -0800

Pekka,

You can pull a similar sort of revision history for any number
of documents that are now RFCs or soon will be. Your message
is what once would have been referred to as "yellow journalism"
and not befitting a dedicated technologist such as yourself.

Fred
[email-masked]

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 20 Nov 2003 18:38:59 +0100

Pekka,

Sorry to say this, but I completely agree with Fred. Do you want a few examples ?

I think is not fair this type of messages from a chair. You should be very neutral (unless you clearly state "hat off").

Regards,
Jordi

----- Original Message ----- 
From: "Fred Templin" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 20, 2003 6:37 PM
Subject: Re: ISATAP spec stability [Re: ISATAP and admin/IP domains]

>  >>(2) above best describes the case for ISATAP as I understand it.

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Nov 2003 20:46:18 +0200 (EET)

> Sorry to say this, but I completely agree with Fred. Do you want a

Sorry for the statistics; maybe they didn't convey enough information.
Of course, there is no problem issuing drafts when things get fixed.  

However, having reviewed the document a couple of times, The changes 
seem to be mostly rather substantial. (Each time I look at the draft, 
I keep wondering why there are more issues to fix than after the 
previous time I sent in comments.)

If you want to have another angle at it, maybe a wdiff output about
changes in the words might help:

draft-templin-ngtrans-v6v4compat-01.txt: 4628 words  2231 48% common  334 7% inserted  2063 44% changed
draft-ietf-ngtrans-isatap-00.txt: 4863 words  3516 72% common  415 8% inserted  932 19% changed
draft-ietf-ngtrans-isatap-01.txt: 4220 words  3079 72% common  281 6% inserted  860 20% changed
draft-ietf-ngtrans-isatap-02.txt: 4295 words  3730 86% common  212 4% inserted  353 8% changed
draft-ietf-ngtrans-isatap-03.txt: 4090 words  977 23% common  804 19% inserted  2309 56% changed
draft-ietf-ngtrans-isatap-04.txt: 4196 words  3499 83% common  267 6% inserted  430 10% changed
draft-ietf-ngtrans-isatap-05.txt: 5082 words  3605 70% common  868 17% inserted  609 11% changed
draft-ietf-ngtrans-isatap-06.txt: 4514 words  4060 89% common  241 5% inserted  213 4% changed
draft-ietf-ngtrans-isatap-07.txt: 5912 words  3157 53% common  446 7% inserted  2309 39% changed
draft-ietf-ngtrans-isatap-08.txt: 6435 words  5273 81% common  877 13% inserted  285 4% changed
draft-ietf-ngtrans-isatap-09.txt: 6459 words  3987 61% common  579 8% inserted  1893 29% changed
draft-ietf-ngtrans-isatap-10.txt: 6786 words  5286 77% common  431 6% inserted  1069 15% changed
draft-ietf-ngtrans-isatap-11.txt: 6309 words  4280 67% common  506 8% inserted  1523 24% changed
draft-ietf-ngtrans-isatap-12.txt: 7038 words  5302 75% common  857 12% inserted  879 12% changed
draft-ietf-ngtrans-isatap-13.txt: 4430 words  3621 81% common  194 4% inserted  615 13% changed
draft-ietf-ngtrans-isatap-14.txt: 4510 words  3635 80% common  366 8% inserted  509 11% changed
draft-ietf-ngtrans-isatap-15.txt: 4740 words  3759 79% common  395 8% inserted  586 12% changed
draft-ietf-ngtrans-isatap-16.txt: 4892 words  2388 48% common  327 6% inserted  2177 44% changed

Now, let's compare that to something else that has been completed,
e.g., 6to4; (I didn't find the previous personal submissions
anywhere):

draft-ietf-ngtrans-6to4-01.txt: 3850 words  2287 59% common  761 19% inserted  802 20% changed
draft-ietf-ngtrans-6to4-02.txt: 5286 words  3390 64% common  766 14% inserted  1130 21% changed
draft-ietf-ngtrans-6to4-03.txt: 5784 words  4237 73% common  953 16% inserted  594 10% changed
draft-ietf-ngtrans-6to4-04.txt: 7033 words  5030 71% common  527 7% inserted  1476 20% changed
draft-ietf-ngtrans-6to4-05.txt: 6980 words  6450 92% common  387 5% inserted  143 2% changed
draft-ietf-ngtrans-6to4-06.txt: 6962 words  6851 98% common  22 0% inserted  89 1% changed
draft-ietf-ngtrans-6to4-07.txt: 7643 words  5974 78% common  580 7% inserted  1089 14% changed
rfc3056.txt: 7595 words  6987 91% common  347 4% inserted  261 3% changed

Take it as you may.  The diffs are against the previous version.
 
> I think is not fair this type of messages from a chair. You should
> be very neutral (unless you clearly state "hat off").

Unless explicitly stated otherwise, I do not wear a hat.

When they made me a co-chair, I didn't agree to be silenced..  
otherwise I would have refused :-).

---

From: Fred Templin <[email-masked]>
Date: Thu, 20 Nov 2003 11:05:25 -0800

I'm sorry, Pekka, but using a one-off example does absolutely nothing
to support your case. If you want to compare against all 3500+ RFCs
in the repository, that's perhaps a different thing - but, throwing a
one-off example in our face is, frankly, immature.

Fred
[email-masked]

---

From: Tim Chown <[email-masked]>
Date: Thu, 20 Nov 2003 21:09:26 +0000

> Of course, there is no problem issuing drafts when things get fixed.  

Hi Pekka,

Fair point.

Any chance you could re-forward your most recent analysis of ISATAP?
(Even if it has changed 44% since :)

Thanks,
Tim