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

Clarification inserted below.

Karen

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of Karen E. Nielsen (AH/TED)
> Sent: Friday, June 25, 2004 11:47 AM
> To: 'Pekka Savola'
> Cc: v6ops@ops.ietf.org; 'Fred Templin'; Mohit Talwar;
> tgleeson@cisco.com; 'Dave Thaler'
> Subject: Security issues of Isatap usage in 3GPP networks WAS : RE:
> moving when all the scenarios are not yet complete [RE: DSTM]
> 
> 
> Hi Pekka, 
> 
> > There is, however, an argument to be made if a mechanism would be
> > required in multiple scenarios, where one or more of the 
> scenarios was
> > not finished yet -- then the question would be what would 
> be the basis
> > on where to evolve the specification? (for example, let's consider
> > ISATAP in 3GPP: one could remove direct tunneling support, 
> but then it
> > might become useless (at least to some) in Enterprise -- for
> > mechanisms which dependencies it might be worth a bit more of
> > wait-and-see, 
> 
> Although I may agree with the above argument in principle,
> I do not agree with the exemplification.
> 
> 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 ?)
> 
> 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.
> 
> 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 additional security check on 
> Isatap interfaces:
> 
> * RA messages are only accepted from PRL routers.
> 
> We have implemented this with no problems and I would 
> like to see it recommended for Isatap.
> 

Fred has pointed out that this
is indeed mandated on Isatap interfaces.
So much the better.

> Indeed:
> 
> 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.
> 
> 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).
> 
> 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)
> 
> 4.1.3: Non-applicable if DAD is omitted
> 
> 4.2.1: Non-applicable given that a trust worthy PRL population
> mechanism is deployed.
> 
> 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.
> 
> 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.
> 
> 4.2.5+4.2.6+4.2.7:
> Non-applicable given IPv4 source address spoofing prevention,
> if trustworthy PRL population mechanism is deployed.
> 
> 4.3.1:
> Non-applicable by IPv4 source address spoofing prevention.
> 
> 4.3.2 
> Not related to the direct tunnelling functionality of Isatap.
> Not applicable if address resolution is based on static 
> resolution only.
> 
> BR, Karen
>