[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FYI Isatap implementations info
Hi,
Please find my Comments in line.
BR, Karen
[snip]
> >
> >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?
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.
>
>
Yes, you're right. The link-local prefix is also accepted.
>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.
>
Yes, packets not fulfilling the above check are silently discarded.
(That is, packets forwarded using Isatap encapsulation
from a router are not accepted.)
> >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.
Yes, I am aware of that.
This was strictly to give the particularities
of the current implementation in use. Not necessary to say
how it should end up being.
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?
>
When I say takes precedence over I (still) mean the following:
First Priority: If the prefix of the source address in the inner
IPv6 header of the encapsulated packet matches a prefix of the
ISATAP interface, the packet is processed by this tunnel interface.
Second Priority: If the prefix of either the source or destination address
in the inner IPv6 header is a 6to4 prefix, the packet
is processed by the 6to4 tunnel interface.
**Here again it should be emphasized that these rules are not intended to
apply to the Isatap router-to-router tunnelling situation.**
I am not 100 % sure what you mean by an on-link 6to4 prefix.
I can imagine that you refer to one of the following 2 situations:
(I)
_ _ _ _ - - - - - - - - - - - - - -
| | ___ | Global Internet/exterior |
| 6to4 |-v6-/ R \ | _ _ _ _ _ |
| Site | \___/-globalV4ADDR-| Intra | |
|_ _ _ _| | -site | |
- - - - - - - - - - - - - -
(II) - - - - - - - - - -
___ | Global Internet/ |
/ R \ | _ _ _ _ _ exterior|
\___/-globalV4ADDR-| Intra | |
| -site | |
| of 6to4 | |
| prefix | |
- - - - - - - - - -
In both situations a packet with the mentioned inner source address
should be from within the intra-site and should be processed by the Isatap
interface and not the 6to4 interface turned towards the exterior.
In (I), then in our 6to4 implementation, the packet with the mentioned source address,
will be discarded by the 6to4 tunnel interfaces as we rely on trusted relay routers.
It wil not be accepted as a packet from a 6to4 border router since the v6 and the v4 sources
don't add up.
In (II)
The packet is a packet coming from and destined for the Intra-site and should
be processed by the intra-site router interface (i.e. the Isatap
interface). Again
the 6to4 interface would discard the packet,
further It should be redirected but thats another matter.
> >
> >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?
>
Intra-site router-to-router is considered out of the question and
is not supported in our implementation.
Whether or not Intra-site host-to-host should be banned in all
situations (and in particular in the situations mentioned
above) is not 100 % clear to me yet (and yes the current
configurations that we deploy, allow for it, but at the same
time we can also easily ban it).
Please let me address this issue in a seperate email.
BR, Karen