Subject: Re: isatap-20 comments

From: Fred Templin <[email-masked]>
Date: Wed, 3 Mar 2004 18:04:31 -0800 (PST)

Pekka,

Thanks for the comments. Sorry for the delay, but I arrived
late at the IETF and this is my first opportunity to respond
(see below):

Fred L. Templin
[email-masked]

--- Pekka Savola <[email-masked]> wrote:
> [as the applicability of different solutions is being evaluated, it's 
> probably OK to use the WG list for discussions as long as they don't 
> too out of hand.. :)]
> 
> Some comments on the latest ISATAP spec.
> 
> substantial
> -----------
> 
> 1) there seems to be a lot of stuff, which doesn't appear to be fundamental
> to ISATAP itself, like:
> 
>  - "Considerations for anycast", 
>  - "must implement basic and advanced API"
>  - ICMP code handling in section 8.6, point 5. 
>  - that pref lifetime mustn't be greater than valid lifetime (sect 9.2.1)
>  - the ICMP code updates are duplicated from the ICMP spec revision (sect
> 11, appendix D)

Agree that it is preferrable to pick up functionality from
normative references whenever possible, but some documents
are currently undergoing revision, i.e., a timing issue.

>  - IPv6 minimum MTU is kind of obvious, in appendix B (but it's in appendix
> so it's not as big an issue)

"Obvious" would seem to depend very much on the reader in
this case; IMO, some readers will find this informative
text useful.
 
> maybe these should be removed if their relevance to ISATAP in
> particular is not made clearer.
> 
> 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"?
 
> 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.

About address rewriting, it seems this will be necessary for NAT traversal.

About MANET derivative work, need some more context to understand this. 

> These should probably be out of scope for the base spec, and pursued
> separately.  Beware of the feature creep....
> 
> 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?

> 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?
 
> 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?

> 6) Very important pieces of the spec appear to be more or less "obfuscated"
> under the management/configuration requirements section, section 7 -- while
> almost none of the issues there are really such requirements.   (I'd also
> specify the MIB objects etc. in another document, as appears to be the
> custom.)

Agree that important pieces of the spec are in section 7. Agree also
on observing the normal custom and specifying MIB objects in another
document.
 
> 7) As the ISATAP model has changed quite a bit during the drafts, I think
> section 4 or the like should probably include a bit more verbose "overview
> of the protocol operation" in the most common cases.

OK.

> 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?

>     +-------+-------+-------+-------+-------+-------+-------+--------+
>     | Type  |Length |   0   |   0   |        IPv4 Address            |
>     +-------+-------+-------+-------+-------+-------+-------+--------+
> 
> ==> might make sense to represent similarly as SLLA/TLLA options in ND spec,
> or at least add "0", "31" and "63" bits at appropriate places..

OK.

>    Native IPv6 and/or ip-protocol-41 encapsulation provides sufficient
>    functionality to support communications between peers that reside
>    within the same site (i.e., the same enterprise network). When the
>    remote peer is in a different site, NAT traversal via UDP/IPv4
>    encapsulation MAY be necessary.
> 
> ==> unless you're excluding to enterprise network (no objections from me
> :-), "i.e." should be "e.g.".

OK.

> ==> s/MAY/may/ ?

OK.
 
> 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.  

>       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.

>    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.

>    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?
 
>    FQDNs are established via manual configuration or an unspecified
>    alternate method.
> 
> ==> might be pretty important for interop purposes.

Suggestions?
 
> Normative References
> 
> ==> there is a very high number of references, even rather obvious ones
> (like "UDP" or "IP").  I'm not sure if this is a big issue, but IMHO at
> least the normative references section could be a bit shorter.  Maybe some
> of these could be removed, or moved to informational references.

Agree.
 
> editorial 
> ---------
> (very good editorial quality -- thanks!)
> 
> 
>       an IPv4 address-to-interface mapping, i.e., a node's IPv4 address 
>       and the index for it's associated interface.
> 
> ==> s/it's/its/

OK.
 
>    See: Appendix C for additional non-normative details.
> 
> ==> s/See:/See/

OK.

> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Mar 2004 04:27:36 +0200 (EET)

A couple of responses inline..

> IPv6 interfaces". Not sure where you derive "default to forward

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.

> 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).

> 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 :)

> 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?  
  
> > in the draft), such considerations should be called out in the security

Nothing specific at the moment.  This would require a lot of
consideration.  I would avoid assuming site-traversal completely.

> 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.

> 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 :).

> 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).

> 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.

> 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..

> > ==> might be pretty important for interop purposes.

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.

---

From: Fred Templin <[email-masked]>
Date: Fri, 5 Mar 2004 18:47:32 -0800 (PST)

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
[email-masked]

Pekka Savola <[email-masked]> wrote:
A couple of responses inline..