[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ISATAP security model wrt. 3GPP networks [Re: 3gpp-analysis-05: miscellaneous non-critical issues]

Pekka,

Pekka Savola wrote:

Let's try not to get sidetracked too much on ISATAP..


Not my intention, but see my brief comments below:

On Mon, 29 Sep 2003, Fred Templin wrote:


So to work around this, you need to use something
to enable you to tunnel to a router in the home network. IMO ISATAP fits nicely in this model.

That's a detail at this point, but this is certainly at odds with the ISATAP security model.


As the lead ISATAP author, I must ask what you see as
the problem with the ISATAP security model in this
context?



The ISATAP spec employs automatic tunneling within a site, trusting the
other nodes in the site (that alone is pretty serious, but it gets worse). When you have access to an ISATAP link, you can do pretty much everything
on that link (especially due to the current, flexibility tradeoffs -- see
Appendix D on the spec).


The RPF checks for ingress filtering in draft -15 are a bit too loose
(hence appendix D) while those in earlier draft versions were a bit
too restrictive. This will be corrected in draft -16 (due out soon),
and appendix D will be removed.

That may be more-or-less fine under a single administrative domain, where
such trust relations may (or may not) be assumed, but in this particular
case, the ISATAP link would consist of the 3GPP operator and all the
ISATAP-using UE's.  Every UE is basically untrusted by the others (and by
the 3GPP operator, but that's not so relevant here).


Not quite true; in the 3GPP environment we have link-layer
authentication mechanisms associated with the IPv4 PDP context
and ingress filtering to prevent IPv4 source address spoofing. Since
the ISATAP RPF checks for ingress filtering build on the link-layer
(IPv4) mechanisms, the IPv4 PDP context provides a trust basis.

Fred
ftemplin@iprg.nokia.com