[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FYI Isatap implementations info

Hello Karen,

Karen E. Nielsen (AH/TED) wrote:

Hi Fred,

In relation to the process of updating the Isatap draft
to comply with existing implementations (provided
that's still the idea -(?))


W/o meaning to speak for the co-authors,  it seems safe enough
to say that the requirement for documenting the widely-deployed
implementations has been clearly communicated by the working
group and understood as first-priority.

you may find the following information useful.


Yes, it was useful; thanks. See below for a few follow-up
comments/questions:

We have made and are continuing using implementations of Isatap
on host as well as on router stacks.
The implementations have been deployed in various
scenarios, though primarily using GPRS and UMTS
IPv4-only access networks.

The implementations are used in configurations which
are largely in compliance with (e.g.) draft-v12 with
the following derivations and/or clarifications:

General:
If not otherwise specified, [mechv02] requirements wrt ND, ICMP etc. over tunnels are fulfilled.

No multicast emulation.
DAD not performed on Isatap interfaces.
Link-layer Address Options not set and always ignored in ND messages received on Isatap interfaces.

MTU scheme based on configurable static MTU.

Host implementation particularities:

Direct tunneling to/from on-link addresses is allowed
(on-link equal to prefixes received in RAs).


To my understanding, "on-link" should also include link-local - correct?

The following security checks are applied
on incoming packets:

Either the v6 src must be on-link and match the v4 src - or the v4 src is from a router in PRL.
In addition RA's are always checked to ensure that
v6 src matches v4 src and that the v4 src must be in PRL.

Router Implementation particularities:

Only Router-to-host communication is supported, that is, PRL list not maintained on Router interfaces. The following security checks are applied
on incoming packets:

The inner IPv6 source address has a prefix configured (i.e. advertised)


Again, to my understanding link-locals should also be included,
whereas "(i.e. advertised)" would seem to exclude them.

on the ISATAP interface and an ISATAP-format interface identifier that embeds the IPv4 source address of the outer header.


Conspicuous by its absence here is the secondary check for
"v4 src is from a router in the PRL", but I note that you have
already stated that the PRL is not maintained on Router interfaces
in your implementation.

v6inv4 Configured tunnels anchored on an Ipv4
address also used by the Isatap interface
will have precedence over the Isatap interface, i.e.,
incoming packets will be processed by the configured tunnel interface implementation and not the Isatap interface implementation.


Agreed.

(Further, Isatap interfaces take precedence over 6to4 interfaces.)


By "take precedence" here, I assume you mean that the received packets
should be decapsulated/filtered as per the specification of precedence
(6to4 or ISATAP) - correct?  This is a (somewhat) unresolved aspect
of the "Re: ISATAP, v6inv4 and 6to4 ..." discussion thread. In further
thinking on this, I believe the correct answer is not quite as simple as
you are stating it here - but almost:

If a 6to4 interface and ISATAP interface are configured over the same
IPv4 address, it would have to be a global IPv4 address assigned to an
interface connected to the global Internet due to 6to4 requirements. In
that case, I believe the correct behavior should be for the 6to4 interface
to take precedence for packets received with an on-link 6to4 prefix in
the IPv6 destination, and for the ISATAP interface to take precedence
for all others. Comments?

For scalability reasons NUD is not performed on Isatap router interfaces.
Further on these interfaces, address resolution is based on static address computation only.

Security threat model:

The above security checks have been modeled
according to environments where the site perimeter
is guarded and where either:
* intra-site IPv4 address spoofing isn't possible (e.g. 3G telecom)
* intra-site nodes are trustworthy


I'm tempted to add a third bullet to your list:

* intra-site communications are restricted to router<->host only

but perhaps this is implicitly covered by one of the other two?

Thanks - Fred
ftemplin@iprg.nokia.com

BR, Karen

-----------------------------------------------------------
Karen Egede Nielsen, System Manager, Ericsson Telebit A/S
Phone: + 45 89385100, Fax: + 45 89385101
Phone Direct: + 45 89385313, Mobile:+ 45 25134336
karen.e.nielsen@ericsson.com
-----------------------------------------------------------