RE: Security issues of Isatap usage in 3GPP networks WAS : RE: mo ving when all the scenarios are not yet complete [RE: DSTM]

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 29 Jul 2004, Karen E. Nielsen (AH/TED) wrote:
> > I think we are pretty close to agreeing that with additional
> > simplifications to ISATAP spec, and significant assumptions about
> > deployment (border is secured; ingress filtering is deployed; etc. --
> > I don't think they hold in general!) ISATAP's security threats from ND
> > can be mitigated reasonably well.
> > 
> 
> I am very glad that we start agreeing on this. 
> 
> So given that this gets to be written down in some
> consolidated form, then it seems (for now at least) 
> that we may agree that the ND aspects of the
> direct tunnelling feature of Isatap isn't 
> in itself what constitutes the major showstopper in 
> the particular environments described.

Yes, with the further simplifications etc. we discussed.

(It still scares me, but I don't see clear, direct threats.)

> > Note that ISATAP's securit model wrt. RFC3756 would be:
> > 
> >    3.  A model where the nodes do not directly trust each other at the
> >        IP layer.  This model is considered suitable for e.g., ad hoc
> >        networks.
> > 
> > .. even if IP spoofing had been prevented, the perimeter secured, etc.
> > 
> 
> In 3GPP networks yes, in Enterprise networks no.

Agree.

> > In addition, direct tunnelling brings up the same link-local
> > threats in other protocols, such as MLD.  Those are likely subject
> > to other forms of threats.
> 
> Could be. Do you have other examples besides MLD ?

That's a large number (e.g., VRRP, OSPF, PIM, etc.), but I don't know
how many of them are used in this particular environment.

> > > In 3GPP networks it should be possible to assume the following:
> > > 
> > > * Intrasite IPv4 source spoofing isn't possible.
> > > * Site is Protocol-41 perimeter guarded.
> > > 
> > > - or it should be acceptable to recommended the above to be 
> > > enforced by the 3GPP operator as a mechanism to prevent 
> > > potential SEND security threats of Isatap.
> > 
> > (This is not all of the threats, but still..) How realistic is it
> > that these are being performed?
> 
> Both are readily feasible.
> The validity in real networks will have to be ascertained,
> will be back...

Will be interested to know.. During my years as an operator, I've seen
way too many pieces of equipment that couldn't do strict uRPF easily
out of the box...

This is one reason why this scares me.  It's really easy to deploy
ISATAP in an insecure manner.. you have to have ingress filtering
everywhere, you have to block external proto-41 connectivity, your
implementations must implement the full spec, etc. -- that's a large
number of considerations which all must be done properly.

[snip]
> > > 4.3.2 
> > > Not related to the direct tunnelling functionality of Isatap.
> > > Not applicable if address resolution is based on static 
> > resolution only.
> > 
> > This is slightly different with ISATAP.  Instead of the router having 
> > to do lots of ND lookups (which time out), the router has to send the 
> > packets to arbitrary IPv4 nodes by static computation.
> > 
> 
> Right. 
> 
> The static computation step may compare with the
> tunnel (endpoint) determination step that a stateful 
> tunnel encapsulation mechanism would have to perform. 
> 
> (The difference in between a stateful and a stateless (like Isatap)
> being that packets only are forwarded encapsulated to IPv4 endpoints
> of established tunnels, not to arbitrary Ipv4 nodes within the
> site.)

Yes.

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