Subject: (ngtrans) isatap-04 old issues (2)

From: Pekka Savola <[email-masked]>
Date: Mon, 22 Apr 2002 19:31:30 +0300 (EEST)

Hello,

(At the end.)

I believe Security Considerations should discuss even the more marginal 
issues:
 - isatap.domain.com being public without precautions, telling the 
potential attacker which source address to try in the spoofing attempts, 
to try to attack against etc.
 - internal addresses in the ISATAP address.

I don't think it's necessary to solve these issues, but I believe it would
be responsible to alert the admins/users to these relatively minor issues
too.

Do other people than the authors believe these should be omitted on 
purpose?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---------- Forwarded message ----------
Date: Thu, 07 Feb 2002 15:15:19 -0800
From: Fred L. Templin <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-isatap-03.txt

Hi Pekka,

Thanks for taking the time to review the spec and comment. Please
find our responses to your comments below:

Fred Templin (for the other authors)
[email-masked]

P.S. I notice Vlad has also commented on this, and his responses look
     fairly consistent with the authors' concensus.

Pekka Savola wrote:
> 
> On Fri, 1 Feb 2002 [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Next Generation Transition Working Group of the IETF.
> >
> >       Title           : Intra-Site Automatic Tunnel Addressing Protocol
> >                           (ISATAP)
> >       Author(s)       : F. Templin et al.
> >       Filename        : draft-ietf-ngtrans-isatap-03.txt
> >       Pages           : 15
> >       Date            : 31-Jan-02
> 
> I read this more thoroughly for the first time on a flight.  Sorry if I'm
> bringing up dead and buried issues.
> 
> Abstract
> 
>    This document specifies the Intra-Site Automatic Tunnel Addressing
>    Protocol (ISATAP) that connects IPv6 hosts and routers (nodes) within
>    IPv4 sites. ISATAP is a transition mechanism that enables incremental
>    deployment of IPv6 by treating the site's IPv4 infrastructure as a
>    Non-Broadcast Multiple Access (NBMA) link layer.
> 
> ==> add 'for IPv6'.

Good point - taken for the next draft revision.

> ==> Usually in the drafts the abstract is after 'status of this memo'
> preamble, not before?

Agreed - also taken.

> 3.  Terminology
> 
>    ISATAP interface:
>      a node's attachment to an ISATAP link.
> 
> ==> shouldn't this be called pseudo-interface?

We are certainly open to other opinions on this. But, since we're defining
the term here (and only for use in this document) whether/not to introduce a
new term such as "pseudo-interface" seems like a matter of personal preference.
RFC 2461 sets the example for IPv6 neighbor discovery over specific link layer
documents, and it does not define "pseudo-interface" - neither does RFC 2893,
which sets the example for auto-tunnelling mechanisms. Both of these documents
are normative references for ISATAP. RFC 3056 defines "6to4 pseudo-interface",
but it is an informative reference (not normative) for ISATAP.   

>    ISATAP address:
>      an IPv6 address with an ISATAP prefix and an ISATAP format interface
>      identifier constructed as specified in section 4.
> 
> ==> The IPv6 address does not have an ISATAP _prefix_ as such (the prefix
> applies to EUI64 part).
> 
> ==> perhaps direct reference to 4.1?

We also define 'ISATAP prefix', thus an ISATAP address must satisfy
both conditions (i.e., have both an ISATAP prefix and an ISATAP format
interface ID).
 
> 4.1.  ISATAP Interface Identifier Construction
> [...]
>       0xFF         TSD is interpreted based on TSE as follows:
> 
>                      TSE          TSD Interpretation
>                    ---          ------------------
>                    0x00-0xFD    RESERVED for future IANA use
>                    0xFE         TSD contains 24-bit EUI-48 intf id
> [...]
> (to the end of section 4.1)
> 
> ==> this seems like a very bad case of overspecification.  _What_ use is
> this, really?  Why would anyone need EUI-48 special case for ISATAP?

Not needed for ISATAP, but specified to provide generic rules for [EUI-64]
interface identifier construction when the IANA-assigned OUI of '00-00-5E'
is used. This language is being proposed for adoption by IANA.
 
> 4.2.  Stateless Autoconfiguration and Link-Local Addresses
>     3FFE:1a05:510:1111:0:5EFE:8CAD:8108
> [...]
>      3FFE:1a05:510:1111:0:5EFE:140.173.129.8
> 
> ==> s/a/A/g

Taken.
 
> 4.3.  ISATAP Link/Interface Configuration
> 
>    [...] ISATAP interfaces MAY be assigned one per link-
>    layer address, or as a single interface for multiple link-layer
>    addresses.
> 
> ==> Multiple ISATAP interfaces..

We didn't quite follow this; are you suggesting alternate text?

>    In the former case, the address of each ISATAP interface SHOULD be
>    added to the Potential Routers List.
> 
> ==> Add a reference to the section where PRL is first discussed.

Taken.
 
> In the latter case, the inter-
>    face will accept ISATAP packets addressed to any of the IPv4 link-
>    layer addresses, but will choose one as its primary address, used for
>    sourcing packets. Only this address need be represented in the Poten-
>    tial Routers List.
> 
> ==> why should this be supported?  AFAICS, it only makes the checks more
> difficult as the packets would not be originated from where they're sent
> to.

This is analagous to having a single primary address and multiple "alias"
addresses assigned to an ordinary interface. The interface accepts packets
addressed to the primary address or any of the alias addresses, but always
sources packets using the primary address. This does not complicate the
validity checks in any way, and seems like a legitimate configuration
option that should not be disallowed. It MAY also be useful to keep the
Potential Routers List short. 
 
> 4.5.  Validity Checks for Received Packets
> 
>    ISATAP interfaces MUST silently discard any received packets that do
>    not satisfy ONE OF the following validity checks:
> 
> ==> ONE of
> 
> ==> Is this really 'not satisfy ONE and ONLY ONE', or inprecise language?
> "at least one" ?

"at least one" is the correct interpretation. We will work on disambiguating
the text.

>      - the link-layer (IPv4) source address is in the Potential Routers List
>        (see section 5.2), i.e., previous hop is an on-link ISATAP router
> 
> ==> should this address embed an ISATAP address?  (note: there are no
> checks specified in 6.1 either)

If you mean "should the network-layer (IPv6) source address embed an ISATAP
address", the answer is no. The only requirement we are asking to be satisfied
by this check is that the previous hop is an on-link ISATAP router. The only
information we get about the previous hop is the IPv4 source address, i.e.,
the IPv6 source address comes from the true source - not the previous hop. 
 
> 5.1.  Address Resolution
> 
>    The link-layer address option used in [DISC] is not needed. Implemen-
>    tations SHOULD NOT send link-layer address options in any Neighbor
>    Discovery packets, and MUST silently ignore any such options in
>    Neighbor Discovery packets which are received.
> 
> ==> "Link-layer address options SHOULD NOT be sent ..."
> 
> ==> s/in Neighbor Discovery packets which are received/
>       in received  Neighbor Discovery packets/

Taken on both counts.
 
> 5.2.1.  Conceptual Data Structures
> 
>    ISATAP nodes use the Prefix List and Default Router List conceptual
>    data structures exactly as specified in [DISC,5.1].
> 
> ==> I'd say this:
> "
>    ISATAP nodes use the conceptual data structures Prefix List and
>    Default Router List exactly as specified in [DISC,5.1].
> "

Taken.
 
>    When the node enables an ISATAP link, it initializes the PRL with
>    IPv4 addresses discovered through name service lookups for the Well-
>    Known Service name "ISATAP" (see "IANA Considerations").
> 
> ==> I thought WKS was for port numbers etc. mostly....

Our terminology is loose here. We are seeking to add the name "ISATAP"
to the "Protocol and Service Names" assigned numbers document found at:

  http://www.iana.org/assignments/service-names

This is to provide a well-known name for name service lookups. We are
NOT asking that DNS WKS RR's be used for encoding IP addresses associated
with the name "ISATAP", however; when DNS is used, we expect that ordinary
"A" records will be used for this purpose. We will work on better text
for this.

> Initialization of the PRL through
>    static IPv4 address assignments and/or an alternate name for lookups
>    is a supported configuration option, but the method described above
>    is preferred.
> 
> ==> "supported" is a bad word in an IETF draft when the behaviour isn't
> described in the document.

How does this sound:

 "Implementations MAY OPTIONALLY support initialization of the PRL through
  static IPv4 address assignments and/or an alternate name for lookups.
  But, the method described above is preferred."

> 5.2.4.  Host Specification
> 
>      MinRouterSolicitInterval
>                    Minimum time between sending Router Solicitations
>                    to any router. Default and suggested minimum: 15min
> 
> ==> It may be just me, but this seems awfully familiar to RFC2461
> "MinRtrAdvInterval"; is this enough to set this off as a host-only, NBMA
> switch?

RFC2461, sections 6.2.1 and 6.3.2, both say: "The specific variable names
are used for demonstration purposes only, and an implementation is not
required to have them...". Should we add similar text to address this
concern?

>    When the host receives a valid Router Advertisement (i.e., one that
>    satisfies the validity checks in sections 4.5 and 5.2.2) it processes
>    them in the same manner described in [DISC,6.3.4]. The host addition-
>    ally resets the timer associated with the PRL entry that matches the
>    network-layer source address in the Router Advertisement. The timer
>    is reset to either 0.5 * (the minimum value in the router lifetime or
>    valid lifetime of any on-link prefixes advertised) or MinRouterSoli-
>    citInterval; whichever is longer.
> 
> ==> If something bad happens to the router, it takes on average at least
> 7.5 minutes to detect it -- whole this time, the packets could have ended
> up in dev/null ?
> 
> ==> If a router advertises even a relatively short time (>1hr), the timer
> goes to 1 hr.  If something bad happens to the router (e.g. a total crash,
> renumbering), it takes on average 60/2 = 30 minutes (the DNS lookup)  to
> recover?
> 
> ==> that is, my worry is host-router NUD

In section 5, we say:

   "ISATAP links SHOULD implement Redirect, Neighbor Unreachability
    Detection, and next-hop determination exactly as specified in [DISC]."

and the scenario you mention above is one intended purpose for this;
NUD would result in our avoiding the unreachable router.

> 6.1.  Host And Router Deployment Considerations
> 
>  Note that the prefixes used on the
>    ISATAP and native IPv6 interfaces will be distinct.
> 
> ==> How so?  Do you mean EUI64 "prefixes"?

No - the IPv6 prefixes; see again the terms "ISATAP prefix" and ISATAP
address" defined in section 3.
 
> 7.  IANA considerations
> 
>    We propose that IANA adopt the interface identifier construction
>    specified in section 4.1 for the existing IANA IEEE OUI registration
>    ('00-00-5E').  Additionally, we request that the name "ISATAP" be
>    reserved in the IANA "Protocol and Service Names" assigned numbers
>    document.
> 
> ==> as mentioned, the last sentence makes no sense to me.  Perhaps I'm
> missing something.

Hopefully, the response to your related comment above will help with this.

> 8.  Security considerations
> 
>    If IPv4 source address filtering is not correctly implemented, the
>    validity checks in section 4.7 will not be effective in preventing
>    IPv6 source address spoofing.
> 
> ==> there is no such section.

Good catch; this is now setion 4.5.
 
>    If filtering for ip-protocol-41 is not correctly implemented, IPv6
>    source address spoofing is clearly possible, but this can be elim-
>    inated if both IPv4 source address filtering, and the validity checks
>    in section 4.7 are implemented.
> 
> ==> this is an all-or-nothing: why not match IPv4 source with IPv6 source
> -- no need to worry about this all that much then.

We only accept packets received from either a) an on-link ISATAP neighbor or
b) an on-link ISATAP router. Your check above is only useful for case a); in
case b), the IPv6 source can be any IPv6 source address and our check comes
down to looking for IPv4 source being an element of the PRL.
 
> ==> note: any node can mask as the ISATAP router in PRL inside the site
> with no IPv6 filtering if above does not hold.

I think the above statement is true regardless of the previous statement.
I think it is also true in the general case for any IPv4/IPv6 communications.
 
> ==> a few additional threats:
>  - the IP address of the ISATAP router can be snooped from DNS remotely
> unless it's protected (e.g. with multiple views)

We believe this is true if and only if all of the site's "private" DNS
RR's could also be snooped. Responsible site security management should
probably protect against this in the general case; not just for the name
"ISATAP". Whether the "ISATAP" RR's are snooped remotely through DNS, or
guessed by some other means, attacks are stopped by ip-proto-41 filtering
at the site's borders.

>  - if IPv4 private addresses are used, behind-the-NAT topology is revealed
> to outsiders through IPv6 address suffixes.

We were aware of this, but do not sense it as a significant threat.
 
> --
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords