[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: isatap-20 comments
Pekka,
Thanks for the valuable input and will give it the appropriate consideration
in determining the best way forward. Will respond in more detail as soon
as possible.
Fred
A couple of responses inline..
On Wed, 3 Mar 2004, Fred Templin wrote:
> > 2) the specification (sect 7.4) appears to default to forward between
> > interfaces -- was this intentional ??
>
> The text says: "ISATAP interfaces are configured as advertising
> IPv6 interfaces". Not sure where you derive "default to forward
> between interfaces"?
Seems like a pretty obvious implication, following RFC2461:
6.2. Router Specification
[...]
6.2.2. Becoming An Advertising Interface
The term "advertising interface" refers to any functioning and
enabled multicast interface that has at least one unicast IP address
assigned to it and whose corresponding AdvSendAdvertisements flag is
TRUE. A router MUST NOT send Router Advertisements out any interface
that is not an advertising interface.
> > 3) the
specification appears to incorporate a lot separate ideas about
> > topics which really seem to have very little to do with ISATAP, such as:
> >
> > - new IPv4 packet reassembly algorithms (section 8.2, first point)
> > - advanced MTU handling mechanisms
> > - some address rewriting stuff (sect 8.6, point 4, 2nd paragraph)
> > - how advertised MTU doesn't affect link MTU (9.2.2.3), but is used between
> > hosts
> > - (some MANET derivative work?)
>
> The fragmentation/reassembly/MTU section provides considerations for avoiding
> harmful network-based IPv4 fragmentation, whereas other mechanisms tend to
> simply set LinkMTU to 1280 and congratulate themselves on a job well done.
> IMO, these considerations need to be spelled out somwehere.
But is this document the right place to do so?
> About MANET derivative work, need some more context to understand this.
I meant, looking at the system in general ("advertising interface")
etc. this seemed like to geared to solve some unspecified problems in
MANET-like networks .. which would be a bad idea, because that is nt
the goal of the mechanism (at least in the scope of v6ops).
> > 4) you mention authenticated RA, but don't specify how:
> >
> > 6. If the packet is "INCOMPLETE" (see section 8.2) prepare an
> > authenticated, unsolicited Router Advertisement message
> > [...]
>
> Perhaps a forward reference to section 9 would fix this?
The problem is that you don't specify how to create an *authenticated*
RA message. Creating a regular RA is probably straightforward enough,
I think :)
> > 5) as mentioned before, security considerations should list implications of
> > administrators not properly maintaining the PRL lists, and what actions they
> > must take, precisely, to
prevent anything bad from happening.
>
> It seems there may be another document that already speaks to this;
> perhaps a reference to the other document would suffice?
I am not aware of the existence of such a document. Maybe you should
clarify what you're referring to?
> > Also, now that the mechanism includes NAT traversal to cross site boundaries
> > (well, the boundaries can be crossed otherwise as well, but you stated this
> > in the draft), such considerations should be called out in the security
> > considerations.
>
> Suggestions?
Nothing specific at the moment. This would require a lot of
consideration. I would avoid assuming site-traversal completely.
> > semi-editorial
> > --------------
> >
> >
> > The following example diagram depicts the ISATAP conceptual model:
> >
> > ==> well, at least I had trouble
figuring out what the figure wanted to
> > represent...
>
> Any suggestions on what to do with the figure?
Try to make it "less intense", by reducing the number of links, sites,
lines, etc. -- simplicity is easier to understand.
> > 8.1.2 Multicast
> >
> > ISATAP interfaces encapsulate packets with IPv6 multicast destination
> > addresses using a mapped Organization-Local Scope IPv4 multicast
> > address ([RFC2529], section 6) as the destination address in the
> > encapsulating IPv4 header.
> >
> > ==> might not hurt to spell this assumption about v4 multicast better.
>
> It seems that any assumption made today might be obsoleted tomorrow
> through operatonal practices. Prefer to leave this as-is.
That is true enough -- such considerations would probably need to be
separate from the body of the specification, e.g., in an operational
considerations section, introduction or whatever.
If we had multicast on the sites, we could have gone the way of 6over4
long time ago, and ISATAP would never probably even gotten started.
And that was over 5 years ago. I don't think the situation has
changed significantly :).
> > For packets received on an ISATAP interface, the IPv4 source
> > address is correct if:
> > [...]
> > - the IPv6 source address is the address of an IPv6 neighbor on
> > an ISATAP interface associated with the locator that matched
> > the packet (see: section 7.2.3), or:
> >
> > ==> I didn't understand what this implied, precisely. Section 7.2 was
> > difficult to understand anyway.
>
> The implication is similar to the "weak/strong" end system model as
> defined by STD3 (referenced under "terminology"), i.e., it should be
> permissible to accept a packet from a neighbor
even if it arrives
> on a different interface attached to the same site.
You mean the case where the peer uses IPv6 address X on its packet,
but the IPv4 packet was sent over another interface whose address
didn't match X? This seems like a rather complicated procedure from
the security check POV. IMHO, it would probably be much easier to
specify that when encapsulating, pick v4 address which matches the v6
address -- and if you want more of them, just add more ISATAP
addresses (for each v4 address you want to use for ISATAP).
> > 4. Perform IPv4 ingress filtering (optional; disabled by default)
> >
> > ==> it might not hurt to specify what exactly you mean with ingress
> > filtering.. it's used in many different ways, so folks may have different
> > assumptions about what it entails..
>
> The meaning here is exactly the same as for RFC2827 IPv4 ingress filtering
> as
specified in ([MECH], section 3.6), which is referenced normatively.
I mean, do you mean like:
- unicast reverse path forwarding,
- filter out your own addresses (or some other bogus addresses), or
- filtering out private addresses or whatever
This seems to vary from time to time. Typically it should mean at
least the first. Maybe MECH needs to be looked at as well, just to
make sure what is meant here.
> > 6. If the packet is "INCOMPLETE" (see section 8.2) prepare an
> > authenticated, unsolicited Router Advertisement message
> > ([RFC2461], section 6.2.4) with an MTU option that encodes the
> > maximum of "ACTUAL_BYTES" and (68 bytes minus the size of
> > encapsulating headers.)
> >
> > ==> IPv6 MTUs lower than 1280 are ignored so 68 bytes minus anything is a
> > no-op. This might fail otherwise as well.
>
> As long as we also specify how RAs received on
ISATAP interfaces
> are processed it should be OK - right?
I personally don't think it makes sense to add special casing in the
ND code for ISATAP, because ND processing those is not
interface-specific, for this. This also has the problem of trying to
get around the IPv6 specified requirements..
> > FQDNs are established via manual configuration or an unspecified
> > alternate method.
> >
> > ==> might be pretty important for interop purposes.
>
> Suggestions?
Sorry, I think I misread this. You're specifying that FQDN to be
looked up must be specified manually. There's obviously no need for
interop requirements here (as long as the implementation processes all
the addresses returned, not just the one which happens to come first
in getaddrinfo). On the other hand, to make this really useful, there
would have to be a specific name to be looked up by default, but there
are
some dragons there -- and these kind of "automatic discovery"
mechanisms need a lot of thought.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings