[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-ngtrans-isatap-21.txt
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: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of Fred Templin
> Sent: 17. april 2004 02:22
> To: IPv6 Operations
> Cc: dthaler@microsoft.com; mohitt@microsoft.com; tgleeson@cisco.com;
> ftemplin@iprg.nokia.com
> 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)
> ftemplin@iprg.nokia.com
>
>
>