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

Re: Getting the features chart going



Hi Bernard,

Bernard Aboba wrote:
> 
> >The only meaningful drawback I've heard of
> >so far pertains to the additional overhead required for the extra SA,
> >and this is really more of an optimization issue than anything else.
> 
> The creation and deletion of SAs that will result from this could limit
> scalability, so I think that a decent case has been made for allowing
> ISAKMP-cfg to assign IP addresses. However, that's *all* that I think
> it should do. Everything else should be handled by DHCP INFORM. That's
> the conclusion we came to in the PPP working group back in the early
> 90s.

I sort of see your point, but think it becomes a bit more muddled when
you look at what is meant by "allowing ISAKMP-cfg to assign IP
addresses". Does this mean the sgw also runs a dhcp server? Does it mean
that we embed a dhcp (bootp) relay spoofer within the isakmp code? If
scalability is an issue here, what do we consider to be the *practical*
limits by which we judge this?

> >It's not clear that isakmp-cfg is simple, and it's also not at all clear
> >that the additional challenges it presents in terms of analyzability,
> >reliability, etc. with respect to security are worth the overhead gains
> >over the dhcp approach.
> 
> There are security risks associated with assignment of IP addresses;
> these threats are detailed in the authenticated DHCP draft. However,
> those threats mostly have to do with unauthenticated clients making
> large numbers of resource requests, or unauthenticated servers handing
> out bogus parameters. In this particular case, ISAKMP-cfg is only
> invoked *after* mutual authentication so that both sides know who
> they are talking to. That doesn't mean that the initiator or
> responder can't act badly, but it does imply that you'll know who
> is doing it. This is about as much assurance as you get with
> authenticated DHCP.

I wasn't referring to the assignment of IP addresses. I was referring to
the complexity of the sgw, the ike code, etc., and to the fact that as
the complexity increases, the analyzability decreases rapidly. At the
same time, the probability of the presence of an exploitable hole
increases. I think that the most secure sgw is (probably) the simplest
possible implementation, and that's what I was driving at.

Scott


Follow-Ups: References: