Subject: Re: (ngtrans) ISATAP-04 comments/questions

From: Jason Goldschmidt <[email-masked]>
Date: Thu, 13 Jun 2002 15:28:53 -0700 (PDT)

Hi Fred,

Thank you for the prompt response, my replies are below ...

>>I have some comments pertaining to the most recent revision of the ISATAP 
draft 
>>(version 4).  These comments and questions come from my perspective as an 
ISATAP 
>>implementor.
>>
>>In Section 5.2.1, the authors discuss initialization and updating of the PRL 
by 
>>ISATAP nodes.  As an implementor, it is not clear how an ISATAP node is to 
know 
>>what naming convention used by the site administrator for the ISATAP routers. 
>>Site administrators might be "encouraged" to use "isatap.domainname", though 
if 
>>they choose something different how should this information be conveyed to 
>>ISATAP nodes?  It appears that manual configuration should always win out, but 
>>what lookups, by ISATAP nodes, should be attempted when no other configuration 
>>is provided?
>>
>ISATAP nodes are expected to lookup the name "isatap.domainname" when
>no other configuration information is provided (assuming the node configures
>a DNS resolver). 

Along the lines of what Alain said, it seem that this could possibly be 
problematic for multitiered domains.  Take for instance a corporate intranet 
which defines both home.domain.com and domain.com.  From your explanation, a 
user in the home domain (possibly a work from home connection the company 
provides) will query for "isatap.home.domain.com".  Where in this particular 
network, the admin has only defined "isatap.domain.com".  With a proper resolver 
configuration, the query of "isatap" will expand to "isatap.domain.com".  Though 
this is different then what you have stated.

>>I wonder if an alternative method, then the one proposed in Section 5.2.1, is 
to 
>>make use of IPv4 anycast to find an ISATAP router (similar to 6to4 Relay 
Router 
>>discovery)?  Has this already been discussed?
>>
>This has been discussed at length over the past several IETF meetings. The
>NGTRANS meeting minutes give a good synopsis of the discussions.

Thanks, I will look there.

>>
>>In Section 8, it concerns me that the authors do not talk about efforts to 
>>secure the PRL or, even point out, that if the PRL is compromised, many 
>>different attacks are possible.  It seems an analogy can be made between a 
rouge 
>>DHCP server being deployed on a network and a compromised PRL being propagated 
>>to an ISATAP node.  This same section states that the PRL provides the policy 
>>for trusting Router Advertisements.  I don't believe this policy can be 
>>implemented if PRL itself can't be trusted (or rather, there is no model 
>>presented in this draft for trusting the mechanism used for PRL 
initialization).
>>
>
>This issue seems to be one and the same as that of being able to trust 
>the DNS
>service within the managed/enterprise network in the general sense. That is,
>nodes implicitly trust resource records they receive from their site's DNS
>service even though this trust could potentially be compromised by "insider"
>attacks. Do you feel that we need to say anything more or less about this
>implicit trust in the case of ISATAP?

In that case, there needs to be a statement about how the PRL is as secure as 
the mechanism for providing it.  This way implementors and admins can understand 
that the most secure mechanism will result in the best protected PRL.

>>
>>Have the authors thought about possible issues that might arise if both ISATAP 
>>and 6to4 are used in the same network or even the same router?  It appears 
that 
>>the security considerations, mentioned in Section 8, might prevent the use of 
>>6to4 in the same network as ISATAP.  It doesn't seem improbable that an ISATAP 
>>router might make use of 6to4 for its IPv6 connectivity.
>>
>We expect ISATAP routers to have at least one link with (non-ISATAP)
>IPv6 connectivity, be it a native IPv6 link or something like 6to4. 

Ah, then possibly the definition of an ISATAP router should include this bit of 
information. 

>One might in fact expect ISATAP and 6to4 coexistence in the same router to
>be a relatively common case. Can you be more specific as to how you
>feel this might be prevented?

Section 8 speaks about ip-protocol-41 filters to prevent IPv6 source address 
spoofing.  What I take from this consideration is that if some other tunneling 
protocol is used by the site to gain access to remote IPv6 sites (6to4 or 
native), then there is potential for attack against ISATAP.  Is my assumption 
incorrect?

One question I forgot to ask in my original message ... In section 6.1 the 
authors discuss discontinuing the 'Router Polling Process' and thus eventually 
deprecating the ISATAP address.  This action is stated to occur "after a 
non-link-local address has been configured and a default router acquired on the 
native link".  What if the address configured on the native interface is, say, a 
site-local address.  Where the scope of the ISATAP address is global.  Should 
the machine still give up its ISATAP address, and thus possibly global 
conectivity, in favor of the site-local address configured on the native 
interface?

thanks,

-Jason

>Regards,
>
>Fred Templin
>[email-masked]
>
>P.S. Please note my new e-mail address above...
>
>

**********************************
Jason Goldschmidt                *
Sun Microsystems		 *
SNT Engineer: IPv6 Project Team  *
(650)-786-3502                   *
[email-masked]             *
**********************************

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 28 Jun 2002 15:38:33 -0700

Jason,

One aspect of Mohit's message clears up a piece of dis-information
which unfortunately originated from me! Mohit is correct that there
is no requirement for an ISATAP router to have global connectivity,
thus there is no text revision required. Sorry for any confusion
my earlier message may have caused.

Fred Templin
[email-masked]

Mohit Talwar wrote:
>>Ah, then possibly the definition of an ISATAP router should 
>>include this bit of information. 
> 
> 
> Well, there is nothing in the ISATAP specification that requires
> this.  An ISATAP router doesn't necessarily need to have global
> connectivity, in which case it will not serve as a default router
> for ISATAP host.  So I am inclined to not revise the definition.