Re: addresses and IKEv2

[Alex Alten <Alten@attbi.com>]

At 02:56 PM 5/17/2002 -0400, Stephen Kent wrote:
>At 11:05 AM -0700 5/17/02, Alex Alten wrote:
>>At 10:42 PM 5/14/2002 -0400, Charlie_Kaufman@notesdev.ibm.com wrote:
>>>This posting points out the tip of a very large iceberg. I think I
>>>understand some of the issues (but I'm not confident); some seem
>>>unsolvable; and some raise questions about the design goals of IPsec.
>>>Attempts to improve things for some scenarios (e.g. Mobile IP) may make
>>>things worse in others (e.g. Address Translation Gateways).
>>
>>Hello Charlie,
>>
>>You raise some excellent points as usual.
>>
>>I have privately thought for a long time that IPsec's dependence on an
>>IP address to determine an SA to be a fundamental flaw in its design.
>>To be effective IPsec needs a global address space, in which each host is
>>uniquely identified, like the Internet was prior to the introduction of
>>NATs, etc.  To make this work a way to dynamically map an Internet address,
>>including duplicate private non-routable addresses, to a global unique IPSec
>>address/identifier needs to be made available.  Each host can then query
>>this database to resolve an IP address to a secure IPsec address/identifier.
>>Cryptography is then used to assure that the IPsec address/identifier is
>>indeed valid.  In this way both MobileIP and NAT can be supported as-is,
>>because they operate on an insecure non-unique IP address, while IPsec uses
>>the parallel universe of a secure unique IPsec address/identifier.
>>
>>However this approach does mean that IPsec can no longer be treated as just
>>a secure protocol, or set of protocols if you include key management. It
>>must be part of a security system, which includes this address mapping
>>facility.
>>
>>Regards,
>>
>>- Alex
>
>Alex,
>
>I assume you have read the new ESP ID from last fall, as well as the 
>new AH ID from this spring, and have followed the WG discussions of 
>why the SA can be determined by examining just the SPI 9without 
>referebce to the destination address), for unicast traffic.  Given 
>that context, I'm not sure I understand your comments above.  Could 
>you clarify?
>
>Thanks,
>
>Steve
>

Steve, 

My comments only apply to the RFCs as they stand today.  SPI is a 
different beast than what I'm discussing even with your latest ESP
ID adjustments.

The fundamental problem is how can we identify a host unambigously in
real time in order to be able to automate the picking of the correct
crypto key used to authenticate it and then bootstrap the SA?  I don't
see the answer anywhere in the RFCs or IDs.  Certainly there are a lot
of documents and maybe I've missed seeing it.  I know that X.509 certs
are not the answer (the bound name/address is too static and can be 
unreliable).

- Alex

 



--

Alex Alten
Alten@ATTBI.com