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

["Soliman Hesham" <H.Soliman@flarion.com>]

 > > => One answer to all of the above: The whole point of recommending
 > > a solution in specific scenarios is to assess the feasability
 > > of the solution to that particular deployment. None of the above
 > > is relevant for 3GPP:
 > >   - On this point to point link ingress filtering in the GGSN 
 > >     stops address spoofing.
 > 
 > If that's enabled, that is.  But as you see, this issue is 
 > not limited 
 > to being (or not being) able to spoof your IPv4 address.

=> So this is a non-issue, ok? If it is, we can add 
a sentence to reflect this requirement.

 > 
 > >   - It's always used in the same admin domain, logically, i.e.
 > >     as far as the IP layer can see.
 > 
 > You misunderstand the concept of administrative domains.  Is 
 > the home 
 > user and his (hers) ISP in the same administrative domain as well?  
 > No, they are not.  3GPP UE is managed by the user, not the 3GPP 
 > operator.  3GPP operator cannot trust whoever uses the UE.  UE users 
 > cannot trust other UE users.

=> Huh??? How is this specific to ISATAP???
Any user can setup a tunnel to a tunnel agent and bomb
someone else. This is the same for MIP. Ok, so you
say the tunnel in other cases is secure and the user 
can be identified. Here the tunnel is not secure of 
course, but the user was authenticated and authorised
for network access and can be tracked. Can you tell
me how this is different from tracking an abusive
MN that floods other nodes through its HA?

 > 
 > >   - 6-to-4 is not recommended and should not be used by end
 > >     hosts. We discussed this several times and even Brian C
 > >     recommended against this a couple of years ago. 
 > 
 > Such recommendation is not grounded on reality.  It is used by hosts
 > by the million, and there is nothing we can do to get it out from
 > there.  

=> By the million? You're right, I'm not grounded in reality.
At least not in your reality....

   I'd suspect many UEs would include 6to4 capability themselves

=> What is your suspicion grounded on?

 > (I seem to recall hearing some UE pilot stacks would have), e.g. for
 > trying to obtain IPv6 access in WLANs.

=> I see.

 > > Given the above conditions, there is no security problems
 > > that we can see.
 > 
 > Perhaps you just don't look sufficiently hard enough :-)

=> I assume you looked pretty hard, please write a threat 
to the list and we can begin from there. I'm talking about
a detailed threat here, not "User A floods User B". This
might be the beginning of a productive discussion.
Unlike the condescending statement above which is an 
end to a discussion.  


 > 
 > To be frank, the argument has sounded a bit like, "we want to have a
 > recommended solution soon, as long as it's the solution we have in
 > mind".  Where are the requirements?
 > 
 > It seems in many cases, a driver for ISATAP has been its
 > auto-discovery function.  Oh really -- that's implementable in about
 > every solution in a dozen of lines of code :).  Not really a good 
 > reason to be blindfolded to just look at one solution, IMHO.

=> I'm not going to go into this again. We had both operators
and vendors supporting this. In Seoul there was no objection
to standardising ISATAP.
You still haven't answered my question, why aren't you asking 
the WG? Normally one person's opinion doesn't reverse WG
concensus. Is this a special case?

I'll move on from this if the WG concensus is to not support
ISATAP in this scenario. 

Hesham