A few responses in-line..
On Fri, 26 Mar 2004, Fred Templin wrote:
On Fri, 26 Mar 2004, Karen E. Nielsen (AH/TED) wrote:I can take this up with the co-authors. Something along the lines of
If you enforce this in the implementation strongly enough, i.e., with a MUST, then this is doable. Could be in the spec.
"must not mix sites over the same IPv4 interface"? There might also
be some text from older versions of the spec that could help.
I haven't been able to follow the discussion on this, so I don't know about the current thinking, but when the thred has ceased, maybe someone will summarize the conclusion.
I agree that this thread should be wrapped up with a concise summary; see below.
I'm not so much concerned about sites getting mixed up (I guess this would assume that different sites the host connects to have different ISATAP domains, and the node could act as a router), but how the implementations could robustly perform their ip-proto-41 decapsulation algorithm so that different tunnels would not get mixed up.
As far as I can tell, configured tunnels will have a specific match on both the source and destination IPv4 addresses in the outer headers of ip-proto-41 packets, while automatic tunnels will have a specific match on the destination but wildcard match on the source - that much seems unambiguous.
(Note: one thing some may be forgetting that the ISATAP interface also includes a link-local prefix, which overlaps with all the other mechanisms (well, except, 6to4 doesn't use them). So, matching the global prefixes is not sufficient..)
The same actually happens with ISATAP and configured tunneling as well. Luckily enough, there should be relatively little overlap with them as well.Here, it would seem normal and natural to find both ISATAP
and configured tunnels configured over the same IPv4 interface.
I would not personally find it "normal and natural" -- because if you have the capability for configured tunnels, you should not be needing ISATAP to begin with (except possibly as an optimization methodbetween the ISATAP nodes inside the ISATAP site).
But I agree that there may be overlap.
ISATAP specifies mechanisms for auto-discovery (and has for a long time now) that add value for the host-router case. It can even be combined with a tunnel broker capability to dynamically create configured tunnels if you'd like, but that is getting beyond the scope of simple mechanisms.
You probably mean that they're in the 3GPP network, yes? It's not really in the same "site" with the ISATAP nodes, then, though.But, wouldn't this depend on whether the ISATAP router sits on the
Even if so, this would address the external proto-41 threats only when the 3GPP operator would perform proto-41 filtering at its Internet-facing borders. And that would not yet even protect against attacks from the other users in the same 3GPP network.
edge of the 3GPP operator network vs. somewhere inside the network?
See more on this below:
...
Sorry if I was confusing here -- by "ISATAP endpoint" I was referring to ISATAP router from the ISATAP host's point of view.
The scenario is like this:
======================||===========+ ||3GPP user 1| admin domain 1 3GPP operator's ||ISATAP node| network ||===========+ ||3GPP user N| admin domain N (ISATAP router) ||ISATAP node| ||===========+ ======================|| administrative domain A
All the users and the 3GPP network are in different administrative domains.
Yes, but if we limit the ISATAP router to occur at the edge of the 3GPP operator network (and not somewhere inside the network), then we have a natural point of demarcation for site boundaries.
E.g., if 3GPP user 1 in your example opens up an IPv4 PDP context, and the 3GPP operator's equipment acts as an ISATAP router on an interface at the outward-facing edge of administrative domain A, then the PDP context would extend admin domain 1 only to the edge of the operator's network and not allow it to penetrate into admin domain A, i.e., there would be no site-overlap.
This would make the interface(s) at the outward-facing edge of admin
domain A appear to be ISATAP router interfaces, and the 3GPP operator's
network would appear as a gigantic ISATAP router with multiple ISATAP
interfaces - one per 3GPP user, i.e., one per customer site. Would this go
toward addressing your concern? And, is there anything more needed in
the spec to support this?
I think you're describing the model where ISATAP is only used for host-to-router tunneling in some sense -- where the host-to-host part was disabled (using some unspecified methods)?
To say it differently, are you proposing the model where a different /64 prefix is advertised to *each* of users, i.e., that each would function as their own ISATAP site (with nobody else in the ISATAP site)? (And the other users would not be "on-link", ISATAP-wise.)
If I understand the scenario sufficiently, I think that would fix most of the concerns. But then again, as takes away the direct tunneling benefit of ISATAP, I'm very uncertain why it would make sense to go into that direction in any case -- as this seems fundamentally like what a configured tunnel set-up does (like STEP or simplied TSP).
Fred ftemplin@iprg.nokia.com