RE: ISATAP vs alternatives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt]

["Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>]

Hi Pekka,

I am replying to the list (I missed that in the first message).


> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: 26. marts 2004 11:51
> To: Karen E. Nielsen (AH/TED)
> Subject: RE: ISATAP vs alternatives in 3GPP [Re: comments on
> draft-ietf-v6 ops-3gpp-analysis-09.txt]
> 
> 
> On Fri, 26 Mar 2004, Karen E. Nielsen (AH/TED) wrote:
> > > ISATAP uses a pseudo-interface (this is especially 
> problematic if the
> > > implementation also has a 6to4 pseudo-interface, and one 
> big reason
> > > why ISATAP should be avoided) 
> > 
> > I agree that this may be a problem if both pseudo-interfaces and
> > anchored on the same IPv4 address - but otherwise I do not see a any
> > problem here.
> 
> Yes.  This is very real if they use the same address.  But from the
> implementation point of view, this is a huge problem.  How do they
> ensure that this won't happen?  Seems like a very difficult thing to
> do.

Well, I don't think that I understand why it is such a problem form the
implementation point of view (I certainly wasn't for us, but then they may be some
autoconfiguration issues that are escaping me).

>  
> > You consider this to be a big issue - does this mean that 
> you consider a scenario
> > where a node would want to establish both 6to4 and Isatap 
> communication 
> > by use the same IPv4 PDP context as likely ?
> 
> I don't think this is practical in 3GPP scenario, but I can see that 
> the mobile nodes would implement 6to4 (for roaming outside of 3GPP).  
> And if they would implement ISATAP as well, a recipe for disaster 
> could be ready.
> 

I am not really worried about the implementation details.

> I don't think the interfaces would be enabled simultaneously in a 3GPP
> network -- because there private addresses are used, and 6to4 is not
> applicable in any case..
>  

I agree, I don't consider the scenario to be even remotely likely.


> >   ISATAP accepts proto-41 packets from
> > > anyone.  
> > 
> > Well a proto-41 packet will be discarded by an
> > Isatap interface/daemon unless it meets a few very specific 
> criteria's....
> 
> Depending on which specification you're looking at, this ranges from 
> "check that v4 and the isatap address match for certain packets, but 
> don't check for the rest" to "practically nothing".  Depends on which 
> spec you're looking at...
> 

May be, but let choose the most solid spec in this sense then.
I assume we are allowed to improve the mechs and perhaps tune them according 
to the applicable scenarios.

> But regardless of that, the fact stands that unless the site operator
> blocks proto-41 at the edge, they can be injected to all the ISATAP
> nodes.  Even if there are checks for such packets, they can cause a
> lot of harm.  Checking that v4 and isatap address match does not help
> that much in that regard, as the addresses are spoofable.
> 

Well typically I think that the Isatap router will be located 
within the site or at the site edge,
therefore proto-41 will not be a problem on the site edge.

> > > ISATAP does direct tunneling between the nodes (even if they
> > > aren't in the same admin domain, if deployed as you propose).  
> > 
> > You mean when nodes attached on different administrative domains 
> > uses the same Isatap prefix/the same administrative domain
> > for Isatap tunnel endpoint, I assume.
> > 
> > That will not be the case in 3GPP if the Isatap service/tunnel
> > endpoint service is provided by the serving 3G ISP 
> 
> No, I mean that if the 3GPP operator provides the ISATAP endpoint, 
> it's in the different administrative domain as the UE.  UE is managed 
> by the user, not the 3GPP operator.
> 

I don't get this - typically the tunnel endpoint will be managed by
some else than the user - right ?

Thanks, Karen


This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.