Subject: RE: draft-ietf-ngtrans-isatap-21.txt

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Tue, 20 Apr 2004 15:19:44 +0200

Hi,

I think that this new draft is excellent and very focused.

FWIW, you may wish to take the following comments into consideration:

Section 7:

The draft refers to [mech] for the basic tunneling 
mech including outer IP header construction, but in principle 
the Isatap draft doesn't say anything about
how the outer header IPv4 destination address is chosen.
Shouldn't there be a section about encapsulation like
in the early Isatap drafts, e.g v12, 
specifying something like:

Encapsulation (from section 6.2 of v12)

   The specifications in [mech] section 3 are used.
   Additionally, the IPv6 next-hop address for packets encapsulated on
   an ISATAP link MUST be an ISATAP address; other packets are discarded
   and an ICMPv6 destination unreachable indication with code 3 (Address
   Unreachable) is returned to the source.

   The IPv4 address of the tunnel endpoint is determined from
   the Isatap interface identifier of the next-hop address.

Section 7.2:

Perhaps is should here be clarified that the PRLs only
are maintained on host interfaces and as such this check does not
apply to router interfaces.

Further, it may be worthwhile to specify the following additional
decapsulation check for Isatap host interfaces:
 - destination address should be an Isatap Address.

Section 8 general:
I miss a section stating that
multicast emulation isn't considered and that DAD
shouldn't be performed as part of address autoconfiguration.

Section 8.2:
"Unsolicited Router Advertisements are not sent on Isatap interfaces"
could be added for clarity.

Section 8.3.2:
Perhaps it would be worthwhile to specify one (or several)
MUST be supported mechanism(s) for PRL population.

A standard FQDN identifier to use for DNS record lookups
should be specified, e.g., "isatap.<domain_name>", where
<domain_name> is the DNS suffix configured on the underlying 
IPv4 interface.

Section 8.3.3:
The following check should also be applied to RAs:
- the ipv6 source address is an 
Isatap address that embeds the Ipv4 source address
in its interface identifier.

(this is not ensured by the "or'ed" rules in 7.2).

Section 8.4:

From a security perspective
as well as from an implementation perspective
I would like to see this section strengthened a bit
 along the following lines:

IPv6 Address resolution on Isatap interfaces consists of two steps:
- Link-layer address resolution
- IPv6 address reachability confirmation

Link-layer address resolution on Isatap interfaces 
is performed by static computation from the Isatap Interface identifier
of the next-hop Isatap address.

Link-layer addresses in Neighbor cache entries on Isatap Interfaces
MUST NOT be used unless they pass the following validity check:
 * Link-layer address must correspond to the Ipv4 address embedded within 
the Isatap interface identifier of the neighbor address.

IPv6 address reachability confirmation is performed by sending 
unicast Neighbor Solicitation 
messages and receiving a Neighbor Advertisment message.

During address resolution then a neighbor entry is considered
in INCOMPLETE state until Reachability Confirmation in form
 of a solicited Neighbor Advertisement has been received.

For security and scalability reasons the
IPv6 address reachability Confirmation step SHOULD be omitted
on Router Interfaces. 
[[FOR DISCUSSION: This behavior could be configurable on Router interfaces.
in trusted environments it could be useful to have NUD on the router also.
Default should be not to perform the reachability step]]

Host SHOULD perform the IPv6 address reachability step when performing
address resolution.
If the IPv6 address reachability step is omitted, NUD will not succeed.

Section 10:

You may wish to take the following observations into consideration:

A number of the threats described in [SENDPS] on Isatap ND are 
non-applicable to and/or easily preventable, Indeed:

4.1.1. Non-applicable given the above mentioned validity check
on neighbor cache entries - that is:
Link-layer addresses in Neighbor cache entries on Isatap Interfaces
MUST NOT be used unless they pass the following validity check:
 * Link-layer address must correspond to the Ipv4 address embedded within 
the Isatap interface identifier of the neighbor address.

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: 
Threat may be prevented all together by specifying that
an Isatap host interface MUST NOT operate with a non-zero PRL list.
That is, host-to-host only scenario not considered.

4.2.3:
Limited to the time in between successive refreshments of the PRL
given that a trust worthy PRL population
mechanism is deployed.

4.2.4
One may want to consider eliminating 4.2.4 of [SENDPS] simply 
(and boldly) by disallowing the redirect functionality on Isatap interfaces. 
The risk of not supporting the redirect functionality is very small;
The Redirect function is generally used to: 
§	Inform Isatap hosts of destinations with Isatap prefixes 
that are directly reachable by ISATAP tunneling from the IPv4 site of the Isatap host. 
§	Redirect Isatap hosts to a better first-hop on-link Isatap router for a specific destination
However, in the first situation above, a correct functioning Isatap host 
will learn of the on-link ISATAP prefixes from the RS/RA exchange performed 
periodically with all routers from its, also periodically updated, PRL list, 
and hence only a limited amount of time can elapse before it would correct its behavior.
The second situation is probably not relevant for ISATAP scenarios given that
router-to-router tunneling isn't supported. Indeed it is our experience that
routers typically only send Redirect messages indicating better 
first-hop router if the egress interface towards this better 
first-hop router for the packet in question is the same as 
the ingress that it received the packet on. In ISATAP scenarios,
 the ingress interface would be an ISATAP interface and 
such an interface cannot be used for Router-to-Router forwarding.

4.3.2:
Non-applicable if the Ipv6 address reachability step of
address resolution isn't implemented on Isatap router interfaces.

Security threats on Isatap ND in secured corporate intranet/enterprises :
------------------------------------------------------------------------

Given that 4.2.2 and 4.2.4 are prevented by specifying a particular behavior
on Isatap interfaces (as indicated right above). Then in accordance with
the table in section 4.4. of [SENDPS] only 4.3.1 remain a real concern
in this environment. This is for further investigation.

Security threats on Isatap ND in IPv4 source proof and protocol-41 perimeter guarded sites:
-------------------------------------------------------------------------------------------

The additional security treats associated with IPv6 neighbor discovery
described in [SENDPS] for the most part are non-applicable or 
can be prevented by simple measures to
Isatap host and routers in sites that are 
guarded against ip-protocol-41 at the perimeter
and for which IPv4 source spoofing isn't possible.

A prime example of an IPv4 source proof and protocol-41 perimeter guarded site
is the network a mobile operator where the GGSN have 
activated IPv4 address spoofing protection
and which in addition implement ip-protocol-41 filtering at the edges.

Note that IPv4 source address proof and ip-protocol-41 
site perimeter filtering together with the Isatap decapsulation rules
effectively establish source proofing on IPv6 Isatap addresses.

The following refer to the threats described in [SENDPS]:

4.1.2: Given Ipv4 source address proof, 
this attack may be prevented by requirering the following validity check
to be applied to received NA messages on Isatap interfaces:
In addition to the validity checks given in RFC 2461 a NA message must
pass the following validity check:
* the IPv6 address in the target field must 
be an Isatap address which embeds the v4 source address.

However it should be noted that this check will disallow ND proxy functionality
on Isatap sites, whether that's undesirable is not clear to me.
(one implication of course would be that the MIpv6 HA service cannot be provided
on Isatap sites but one would never want to do that anyway I think).

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.2.2: 
Spoofed RA message with zero-lifetime is not applicable.
As mentioned above this threat may be prevented all together by specifying that
an Isatap host interface MUST NOT operate with a non-zero PRL list.

4.2.3:
Limited to the time in between successive refreshments of the PRL
 for the same reasons as 4.2.1.
In addition then compromising the Isatap router itself
 is a doubtful scenario in carefully managed networks 
such as e.g. 3GPP/3GPP2 and enterprise networks.

4.2.4:
Is limited by Ipv4 source address spoofing prevention.
In addition then compromising the Isatap router itself
 is a doubtful scenario in 3GPP/3GPP2 and enterprise networks
May be prevented altogether by disallowing the redirect 
functionality on Isatap interfaces as mentioned above.

4.3.1:
Non-applicable by Ipv4 source address spoofing prevention.

BR, Karen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Fred Templin
> Sent: 17. april 2004 02:22
> To: IPv6 Operations
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: draft-ietf-ngtrans-isatap-21.txt
> 
> 
> Hello,
> 
> A new version of the ISATAP specification (isatap-21) has
> been submitted to the I-D registrar and is also available
> for early review at:
> 
>       www.geocities.com/osprey67/isatap/isatap-21.txt
>     
> The purpose of the -21 version is to satisfy the clear requirement 
> for documenting the widely-deployed implementations. We request that
> the -21 version now be adopted as a v6ops wg document.
> 
> Fred L. Templin (for the ISATAP co-authors)
> [email-masked]
> 
> 
>

---

From: Markku Savela <[email-masked]>
Date: Tue, 20 Apr 2004 18:10:59 +0300

I've some problem with section 8:

  ...
  8. Neighbor Discovery for ISATAP Interfaces

   ISATAP nodes use the neighbor discovery mechanisms specified in
   [RFC2461] to create/change neighbor cache entries. ISATAP interfaces
   also implement the following specifications:
  ...

I don't see how a neighbor cache entries would get created. You cannot
run normal RFC2461 neighbor discovery on ISATAP interface to detect
link layer addresses: ISATAP interface does not support multicast!

I think all references to neighbor cache could be removed (there is no
need for link layer addresses). Like, in section 8.4

  ...
  8.4 Address Resolution

   The specification in ([RFC2461], section 7.2) is used. ISATAP
   addresses for which the neighbor's link-layer address cannot
   otherwise be determined (e.g., from a neighbor cache entry) are
   resolved to link-layer addresses by a static computation, i.e., the
   last four octets are treated as an IPv4 address.
  ...

Change above just into

  ...
  8.4 Address Resolution

   ISATAP addresses are resolved to link-layer addresses by a static
   computation, i.e., the last four octets are treated as an IPv4
   address.
  ...

A corollary to above is: ISATAP IPv6 "nexthop address" is always based
on one of the PRL addresses.