Subject: [Rserpool] FW: [mobile-ip] -New ID about Address owernship-

From: "Gopal Ram (NRC/Boston)" <[email-masked]>
Date: Tue, 24 Jul 2001 10:29:30 -0500

Hello Stewart,

I am forwarding an email which happened in HIP mailing list. This will
give you  some hints.
We also considered the HIP in candidate proposal, it requires a
architectural shift.  Apart from the below, it is also very expensive
and it has been discussed  IETF-50 Mobile-IP WG.

Regards
Ramg

>-----Original Message-----
>From: ext Francis Dupont [mailto:[email-masked]]
>Sent: Friday, April 13, 2001 5:01 AM
>To: Robert Moskowitz
>Cc: [email-masked]; [email-masked]
>Subject: Re: [mobile-ip] -New ID about Address owernship- 
>
>
> In your previous mail you wrote:
>
>   >This has negative implications for larger servers that 
>process many 100s
>   >of thousands of connections at a time or for smaller 
>mobile nodes that
>   >are short in processor and battery resources
>   >(you have recognized the argument :-).
>   
>   Similar to WTLS 1.2
>   What kind of server maintains 100,000s of concurrent connections?
>
>=> ask IESG (:-)!
>
>   >An illustration: HIP provides a good protection against 
>DoS attacks,
>   >in fact this is not really an advantage: HIP must provide 
>this because
>   >HIP mechanisms involve a lot of powerful/expensive crypto 
>which could
>   >make DoS attacks very prejudicial...
>   
>   Any key exchange mechanism adds to the risk of DoS attacks, 
>but a well 
>   worked out mechanism should also remove exposure to 
>transport level attacks.
>   
>   For MIP's initial usage of HIP only being used for BUs, 
>HIP's goal would be 
>   to protect the BUs and give the CN's trust in them.
>   
>=> my concern is that HIP does too much. As soon as the exact 
>requirements
>will be available we'll see if HIP is above, below or just at 
>the good level
>of protection/complexity. I believe that it will be above like IKE is
>according to IESG...
>This is not about the merits of HIP but my concern is different: is HIP
>the right tool for mobile IPv6 BUs with random CNs.
>
>   >  The less drafty draft uses only SHA-1 which is far less 
>expensive: the 
>   > exact requirements for mobile IPv6 security are not yet 
>available but HIP 
>   > seems to overfulfill them.
>   
>   To the later, that it may.  SHA-1 is less expensive than 
>any PK crypto, no 
>   one can argue that.  Does 'drafty draft' meet reasonable security 
>   requirements?
>
>=> we need to get the requirements before judging...
>
>   I offer HIP for a number of reasons:
>   
>   I am working on HIP for secure Internet model that 
>understands 'addressing 
>   realms' (like IPv4and v6 co-existing and NAT traversal) and flexible
>   mobility.
>   
>=> but HIP itself doesn't support the mobile-to-mobile case (it lacks
>a fallback mechanism or if you prefer HITs are not routable).
>
>   It is HARD to get a trusted binding between two hosts.  
>Shortcuts tend to 
>   be longcuts, in that they are later found to be flawed; 
>'good enough' (look 
>   at WEP) can end up being no protection at all.  HIP has had 
>a reasonable 
>   peer review and is itself based on other mechanisms like 
>SSL, IKE, SKIP, 
>   and Photuris.
>   
>=> the issue is not that HIP is too weak, it is that HIP is too strong.
>From the security point of view IKE can fulfill all the requirements
>of Mobile IPv6 but it is incredible expensive to use (the first home
>registration from a visited network (the first thing the mobile does)
>works well, including between different implementations, but has
>abyssal performances). It can rely on a global PKI too (like DNSsec).
>All the arguments used against IPsec/IKE applies to HIP too...
>
>   >BTW I like very much the SUCV address idea but section 6.1 should
>   >be simplify/adapted (i.e. not cut&pasted from the HIP document).
>   
>   I do not know if SUCV will be secure, I am studying it.
>
>=> I believe it is secure enough for temporary addresses (military
>argument: short term informations need less protection than long term).
>We have to see for permanent addresses in the mobile IPv6 BUs 
>to random CNs
>context.
>
>   The opportunistic mode of HIP needs further development and 
>I am doing that.
>
>=> this is an important point because "a global PKI is not 
>available and
>perhaps not desirable" (quoting Jeff Schiller).
>
>   Consider for a moment where a BU HELLO is equivalent 
>   in HIP to the I1 HIP packet.  Also note that an 
>optimization of HIP could 
>   allow for a data payload INSIDE of I2 (but not appended 
>after, as the 
>   intiator does not get the responder's SPI until R2).
>   
>   The ESP transform used in MIP for BUs could be ESP NULL with 
>   HMAC-SHA1-96.  Once the initial HIP exchange is completed, 
>ESP is used for 
>   all future exchanges until either a timeout (could be set 
>fairly long here) 
>   or loss of state (CN or MN boot).
>   
>=> I believe the divorce is complete between IPsec and Mobile 
>IPv6 people,
>i.e. the BUs auth* will be provided by an ad-hoc mechanism, not by an
>IPsec transform...
>But if you read the less drafty draft you can find an ESP protection
>for the HA-MN tunnel. This is a VPN-like case so it is 
>apparently readily
>supported by the current generation of IPsec/IKE implementations (:-).
>But the MN (by definition :-) can move so we have again the SA
>rebuild/update issue: HIP can be very useful there and as the HA never
>moves we don't fall in the mobile-to-mobile hard case.
>
>   HIP as written in my 3 IDs is a full protocol.  There is 
>much that others 
>   can do to target it to particular opportunities.
>   
>=> even if HIP is not suitable for the random CN case there 
>are some others:
> - not random CNs (same than the random CN case but with a common PKI
>   or a common trusted third party)
> - permanent home registration (common PKI, trusted third 
>party, AAA, ...,
>   but as this is the principal mechanism (previous cases are 
>optimizations)
>   this is critical for both security and performances)
> - temporary home registration (the smooth hand-off case) (AAA 
>credentials,
>   all involved entities on the same link).
>
>Thanks
>
>[email-masked]
>   
>PS: any mechanism which can reconcile IPsec (mainly ESP tunnel 
>transform :-)
>and mobility based on addresses is *wellcome*!
>

_______________________________________________
rserpool mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rserpool