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

["Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>]

Hi Pekka,

Thanks a lot for your comments !

Some comments inline.

> 
> Going through oooooold backlog...

Lucky you... 

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

> On Fri, 25 Jun 2004, Karen E. Nielsen (AH/TED) wrote:
> > Let me try (once more) to address the expressed concerns with
> > the direct tunnelling functionality of Isatap. 
> > 
> > The problem hinted at, I assume, is the SEND security threats
> > as detailed in 3756 (....or are there others ?)
> 
> RFC3756 on ND security threats should provide a relatively complete
> picture here.  Of course, there are still security issues that might
> be independent of the use of ND that come with ISATAP (for example,
> see my last comment in this mail).
> 

Agree, what I attempted to address was the concerns with
ND and the direct tunnelling feature.

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

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

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

> Still, the ISATAP spec does not (IMHO) include sufficient guidance 
> (just two paragraphs in Security Considerations) what exactly 
> the site 
> should do, and what happens if that isn't done.  This seems too vague 
> to qualify as a sufficient recommendation.  (yes, this has been 
> brought up in the past, but the revisions of spec seem to remove all 
> of this kind of analyses.)
> 
> Also, I seem to recall (I'd be happy to be proven wrong..) that some
> or even many implementations do not perform the required security
> checks (or didn't perform them).  That's not good; a tunneling
> mechanism where you have less to check and rely on is better because
> you don't need to worry about whether a particular implementation has
> done a check or not.
>  

In the very nature of the matter, pre-standard Proto-type implementations 
aren't always fully compliant. 

Anyway, I don't think that we are talking about a lot of security checks here.

> > Given the above, the SEND security threats either do not apply to
> > Isatap or can be prevented by careful implementation. In particular
> > by implementing the following [...] security check on 
> Isatap interfaces:
> > 
> > * RA messages are only accepted from PRL routers.
> 
> See responses below.
> 
> > 4.1.1. Link-layer addresses in potential 
> > Neighbour Cache Entries maintained on Isatap Interfaces
> > are not relevant. The Link-layer address (IPv4 address) is deduced
> > from IPv6 destination address. An implementation that uses 
> a different link-layer address
> > than the IPv4 address embedded within the IPv6 destination 
> address isn't compliant.
> 
> Yes, should be OK in the current spec.
> 
> Note however that you still can populate the neighbor cache with crap
> even if you don't use it with ISATAP.
>  
> > DAD sub-clause:
> > Why you would ever want to implement DAD on an Isatap 
> Interface I really don't know.
> > The uniqueness of the address is inherited from the 
> uniqueness of the IPv4 address.
> > The latter which is ensured by the network (at least in 
> enterprise and 3GPP networks).
> 
> The spec takes no stance on disabling DAD or not for ISATAP, hence it 
> could be used.  However, if v4 spoofing is prevented and perimeter is 
> secure, this shouldn't be a problem.
>  
> > 4.1.2: This could be a valid DoS threat.
> > This is however only applicable if NUD is performed on the 
> interface.
> > NUD over Isatap only really work if carefully implemented anyway -
> > Hence it should be reasonable to assume careful behaviour 
> of an implementation which performs
> > NUD on an Isatap interface. For example by implementing the 
> following additional validity
> > check:
> > * Unless sourced from the link-local address of a PRL 
> router (e.g. for proxy ND) the target address
> > of the NS message should be identical to the source address 
> of the packet.
> > 
> > (We haven't implemented the mentioned check as we 
> > do not support NUD on isatap interfaces)
> 
> I think the critical question here is whether the node processes NS's
> and NA's (and which ones if so) that are sent on the ISATAP link.  
> That's where I'm concerned -- I'd rather restrict ND messages to just
> those we know we need, rather than allow everything and provide checks
> which might or might not help.
> 
> Also, looking at the spec, I can't quickly think of why 
> running NUD on 
> top of ISATAP links would make sense, as NUD only deletes the 
> neighbor 
> cache entry -- but as with ISATAP neighor cache wouldn't be used in 
> any case, always just the static computation, this doesn't seem too 
> useful.
> 
> The only cases I could marginally think of would be the use of some 
> onlink prefixes by PRL routers, but that's marginal as well.
> 
> I guess this could be removed.
>  
> > 4.1.3: Non-applicable if DAD is omitted
> 
> Yes, but more on DAD above.
>  
> > 4.2.1: Non-applicable given that a trust worthy PRL population
> > mechanism is deployed.
> 
> Agreed (and if spoofing is not possible).
>  
> > 4.2.2+4.2.3
> > Isn't related to the direct tunnelling functionality of Isatap.
> > Is limited by the usage of/and management of 
> > a trust worthy PRL population mechanism.
> 
> Wrt, 4.2.2, ISATAP should be better off than standard ND because if 
> the decapsulation checks are implemented, even if the default router 
> is killed, only communication using the ISATAP addresses is possible, 
> others will be discarded.
> 
> 4.2.3 is not an ISATAP-specific issue.
> 
> > 4.2.4
> > Non-applicable as Isatap's source address checks combined 
> with IPv4 source address
> > proof implies IPv6 source address proof. I.e. the IPv6 
> link-local address of
> > a PRL router cannot be spoofed.
> 
> Agreed.
>  
> > 4.2.5+4.2.6+4.2.7:
> > Non-applicable given IPv4 source address spoofing prevention,
> > if trustworthy PRL population mechanism is deployed.
> 
> Agreed -- significant if's.
>  
> > 4.3.1:
> > Non-applicable by IPv4 source address spoofing prevention.
> 
> Yes.
>  
> > 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.)


> You could even perform 6to4-like reflection from the ISATAP router.  
> Assume that the ISATAP addresses would be of the form: 
> 2001:db8::<ISATAP-ID>, and the site used 10.0.0.0/8 for addressing.
> 
> Now you could force the router to send proto-41 packet to 1) every 
> host inside 10/8, or even 2) every host the user wants e.g., a host 
> that's outside the ISATAP domain (e.g., 4.5.6.7) -- unless there are 
> specific blocks at the ISATAP router or at the perimeter to change 
> this.
> 
> It might be possible to avoid 2) for global addresses if the ISATAP
> prefix length is chosen to be sufficiently short and the v4 address
> space is contiguous.  But that would mean having a prefix length like
> /106 which would be disallowed by the IPv6 specs and would probably
> have other problems..

Right. Stateful tunnel mechs have some advantages here.

/Karen