[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Proposed Configuration payload for IKEv2




-----Original Message-----
From: Charlie_Kaufman@xxxxxxxxxxxxxxxx
[mailto:Charlie_Kaufman@xxxxxxxxxxxxxxxx]
Sent: zondag 12 januari 2003 4:02
To: Van Aken Dirk
Cc: ipsec@xxxxxxxxxxxxxxxxx
Subject: RE: Proposed Configuration payload for IKEv2


Hi Charlie,

See my remarks below.



>Wouldn't it be simpler to use DHCP all the way i.e. the construct
>DHCPClient-Relay-Server ?

I initially had the same thought, but was talked out of it. Let me repeat
the logic that convinced me, and see if it does anything for you.

The bottom line is that while I believe this would be possible, I don't
believe it simpler. The problem is that DHCP runs over IP only though heavy
kludgery. Since you don't initially know your IP address, you must send
initial DHCP messages from IP address zero and get responses either via
your hardware address or by multicast.
>>
Not fully correct !
The reason why the hardware address comes into the picture has all to do
with shared media such as Ethernet.
e.g. Take following non-IPSec configuration: an Ethernet segment is
connected to a router. DHCP client requests, which are per definition
broadcasted, are intercepted by the router and DHCP-relayed (that is
unicasted..) to a DHCP server. The server's replies arrive back on the
router's IP interface. How can this IP interface forward these replies back
to the client ? Remember the client still has no IP address hence cannot
answer ARP request. Solution: either use Ethernet's broadcast address
(FF-FF-FF-FF-FF) or use the client's hardware address (being a MAC unicast
address in the Ethernet case) contained in the reply.

Doing DHCP on point-to-point links is quite different and IMHO, IPSec
Tunnels are point-to-point links ...
>>


If we wanted to tunnel these
messages over IPsec protected ESP, we would have to first set up an ESP SA
tunnelling packets from address zero to a broadcast address, and then after
the IP address becomes known set up a new ESP SA with the new address.
>>
Setting up tunnel to and from 0.0.0.0/255.255.255.255;port 67/68 seems not
that complicated to me compared to the cryptographic stuff inside IKE. I
guess it has more to do with implementations that have implemented only
limited IKE functionality.
>>


I would expect some substantial confusion with the packet forwarding tables
on the server, and a lot of special casing.
>>
I cannot follow you here. Of course a method must be implemented to
terminated multiple of such DHCP tunnels simultaneously. More specific you
need a method to tag DHCP request coming out of a tunnel. Via this tag, the
IPSec gateway can forward the responses from the server back into the
appropriate tunnel. Well this is exactly what RFC3046 is intended for i.e.
see RFC3046 section 3.1 Agent Circuit ID sub-option. With slight
modifications this technique could be reused for IPSec.

I guess http://www.strongsec.com/freeswan/dhcprelay/ipsec-dhcp-howto.pdf
implements just that.
>>


Alternatively, we could run DHCP over the IKE SA instead of over a special
ESP SA set up for that purpose, but this requires even more special casing
for what the endnode fills in for hardware address, etc.
>>
To be honest, this approach suffers from the same problem as IKE mode
config: two protocols are intertwined here: IKE for key establishment and
DHCP for IP host configuration.

Why can't IKE and host configuration not be completely decoupled ? More
specific host configuration is "data" that should be protected such as any
other data that needs to be securely transported between two sites.
In addition, watching the discussion on the Internal_Address_Expiry
attribute confirms my opinion on protocol intertwining.

As said before it is PPP-IPCP all over again but then in IKE ...
>>


I would think a not unlikely scenario would be where a user has a permanent
internal IP address and the IPsec gateway wants to assign that internal IP
address based on the user's identity (independent of what address the user
is tunnelling from). This would require more special case kludgery if we
wanted the negotiation to look like DHCP but use other fields from the IKE
messages.
>>
Can you clarify what exactly your scenario is because this type of
"permanent/static" assignments already exists for years in DHCP.
>>

DHCP is capable of carrying lots of kinds of information. Except for
dynamic IP address, all of it is obtainable after you have your IP address
- and in fact it works more smoothly and efficiently once that happens. So
my second thought was that IKE be capable of negotiating an internal IP
address after which DHCP tunnelled over ESP could be used for obtaining any
other information desired. This would work, and it's my understanding that
an endnode could use this mechanism to get DHCP-based information not
available through IKE. Throwing a few more commonly used parameters into
IKE - like the IP address of a DNS server - is clearly unnecessary but will
simplify the common case of implementations that only want that additional
information. I could be convinced either way on that one.
>>
Well, Charlie this is a bold statement: let's say that 70% of the Internet
host either use DHCP directly to obtain their IP address or indirectly (via
constructs such as PPP-IPCP-DHCP or IKE-DHCP). If there would be problems
with this mechanism I guess we would not be discussing right now ...

The real point is the following: is the IKEv2 working group willing to adopt
<draft-ietf-ipsec-dhcp-13.txt> and willing to include a pointer towards this
draft RFC or does it sticks with yet another in-band IP configuration
protocol ?

I prefer the first option and below I enumerate my reasons:
- clean protocol layering/engineering (IKE for secure cryptographic key
establishment DHCP for IP host configuration)
- DHCP runs end-to-end
- only one IP configuration method must be implemented/tested/maintained
versus two in the current situation
>>

Best regards - Dirk
 

I had another objection to the design I added to ikev2-04. If we're going
to negotiate IP address leases over IKE, it would seem like the lease
should last for the duration of the ESP SA rather than expecting the client
to periodically renew it. This would require some additional state on the
server (renewal timers), and would require that the server close the ESP SA
if it were ever unable to renew the lease, but it would simplify the
client, simplify the minimal IKE implementation,
and reduce the number of error states we could get into. I believe this
would be an improvement, but gave in to people who understand this stuff
better than I do. But if others with more confidence would like to argue
about it...

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).