Subject: Re: Modefg considered harmful

From: [email-masked]
Date: Sat, 1 Feb 2003 20:24:53 -0500

While my personal interests are in settling the MODECFG vs DHCP-relay
debate in any way that sticks, I can't resist throwing in my technical
opinion.

The appeal of MODECFG is that it minimizes the number of messages and
crypto operations in getting an IPsec session set up. The appeal of
DHCP-relay is that it provides all of the flexibility and power of DHCP
(including extensions defined in the future) and does so in a way that
appears to make it independent of the IKE specification. But I believe this
appearance is illusory.

For an endnode to acquire an IP address on a remote network for use with
IPsec, there are several things going on - only one of which involves DHCP.
Yes, the address must be leased, but in addition the IPsec gateway
implementation has to begin responding to ARPs to that address and
forwarding packets addressed to that address over the IPsec tunnel. The
IPsec gateway should only accept packets over the IPsec tunnel with source
address equal to one that the endnode has legitimately leased. That means
the gateway can't be a passive relay. It has to parse the messages it is
passing through, and if there are extensions to DHCP in the future that
affect leases on IP addresses, the gateways will have to be updated to
understand them. I believe this is what Cheryl Madson referred to as "a
special state" in the state machine.

So I would claim that the IPsec endnode, the IPsec gateway, and the DHCP
server are running a three party protocol, and it's not obvious whether
it's better to have the IPsec gateway eavesdrop on the DHCP conversation or
be a full participant by acting as a DHCP server to the endnode and a
client to the DHCP server. As a practical matter, MODECFG specifies exactly
what the two participants have to do, while DHCP-relay is more open to
interpretation. Unless DHCP-relay were specified more precisely in terms of
what the IPsec gateway had to do with the information it saw passing by, it
seems likely that MODECFG would give us better interoperability. And if
IPsec gateway actions in response of DHCP messages were specified more
precisely, I believe that proposal would lose must of its extensibility.

The use of MODECFG does not preclude the use of tunnelled DHCP for uses
other than acquiring leases on IP addresses. If I were designing the
protocol, I'd have IKE handle *only* IP address leases (defining the life
of the lease to match the life of the SA), and use tunnelled DHCP for all
other functions (like getting DNS server addresses). Adding a few more
fields to MODECFG enhances performance - probably in a trivial way - but
it's likely that doing so will result in requests for more in the future
(which we can either accept or decline). I could be convinced either way.

In summary, I believe MODECFG as specified will work and will provide few
interoperability surprises. I believe DHCP-relay could be made to work if
it were more tightly specified, but would be more likely to provide
interoperability problems. DHCP-relay does provide some functionality not
possible with MODECFG - in particular assignment of IP addresses based on
additional information about the client. If any of that functionality is
actually needed, it could be added to MODECFG, but I haven't heard a case
for it yet.

          --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).

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 1 Feb 2003 17:41:02 -0800 (PST)

> It has to parse the messages it is
> understand them.

The relationship between the client, IPsec gateway and DHCP server is
"three way" in either case. But the responsibilities of the parties are
quite different.

RFC 3456 states that the IPsec gateway acts as a pure DHCP relay, not a
proxy. This implies, for example, that DHCP authentication (RFC 3118) can
be carried out between the DHCP client and server. This is not
possible with Modecfg, because the IPsec gateway does not have the
credentials to act on the client's behalf. DHCP Relays *do not* need
to understand all the options contained in DHCP packets, since their
primary function is forwarding packets. State is kept on the end systems.
In contrast, with Modecfg, the IPsec gateway needs to implement the
DHCP client state machine (if it talks to a DHCP server).

With RFC 3456, the IPsec gateway *does* need to know the IP address
assigned to the client, for the reasons you state. However, the
lease time is not relevant to operation of a DHCP Relay, because in RFC
3456 address renewal is the responsibility of the client, *not* the
IPsec gateway. The means that the IPsec gateway would not be affected by
definition of new options. And in RFC 3456, there is no need for the IPsec
gateway to also be a DHCP server.

However, with Modecfg, the IPsec gateway is often a DHCP client. This is
problematic, because DHCP is end-to-end. That means that when
the IPsec gateway attempts to renew the address, the reply will ordinarily
come to the client, *not* to the IPsec gateway -- and the client will
not be expecting DHCP packets. As RFC 3456 explains, some
trickery is required to circumvent this, which shortens the time available
for address renewal. One question is whether this could potentially
result in addresses expiring or being assigned to someone else. Since
Modecfg has no facilities for lease expiration or reconfiguration,
that would be difficult to recover from.

> I believe this is what Cheryl Madson referred to as "a

DHCP relays are stateless, so you can't be talking about DHCP state --
which needs to be kept by Modecfg. I assume the state referred to relates
to the IP address -- but that state is required in either case.

> server are running a three party protocol

This is true in either case.

>, and it's not obvious whether
> client to the DHCP server.

RFC 3456 does not require the IPsec gateway to also act as a DHCP server,
since that would require the gateway to implement persistent storage; that
is why only  DHCP relay functionality is required, which is stateless.
However, for the reasons described above, I could see where with Modecfg
that might be a requirement.

> As a practical matter, MODECFG specifies exactly
> interpretation.

The DHCP Relay functionality is specified in RFC 2131 -- and if this was
"open to interpretation" we'd probably have encountered those issues
in the Connectathon bakeoffs.

> Unless DHCP-relay were specified more precisely in terms of

RFC 2131 states the responsibilities of DHCP Relays very clearly. The
primary responsibility is packet forwarding. I think you may be confusing
the operation of a DHCP Relay with a DHCP proxy -- which *is* ill-defined.

> seems likely that MODECFG would give us better interoperability. And if

This hasn't come up in DHCP Relay testing at Connectathon.

> precisely, I believe that proposal would lose must of its extensibility.

The DHCP Relay function is laid out precisely in RFC 2131.

> other than acquiring leases on IP addresses.

In fact, if RFC 1877 is any guide, it's likely that MODECFG clients will
end up doing DHCPINFORM anyway. So what is the point of implementing
MODECFG at all? Why not use DHCPv4 or RA/RS for address assignment?

> If I were designing the
> other functions (like getting DNS server addresses).

That would make more sense. But there is still a problem with doing IP
address assignment within MODECFG -- IPv6 compatibility. Does MODECFG
now duplicate the functionality of RS/RA? Or does it hand out individual
IPV6 addresses? Do we have completely different mechanisms for address
assignment and configuration between IPv4 and IPv6? Why go down that road?
If you're going to tunnel the RS/RA conversation, you end up with
something quite close to RFC 3456 anyway -- so why not handle IPv4 and
IPv6 the same way from the start?

> Adding a few more

As RFC 1877 showed, this is the road to hell. Since we know that we can't
realistically go there, why start?

> interoperability surprises.

And over time will pile up kludge upon kludge to the point where it will
result in lots of unnecessary complexity, IPV6 incompatibility, or worse.

> I believe DHCP-relay could be made to work if
> interoperability problems.

I think you're confusing DHCP Relay with Proxy. There are no major
interoperabilty problems with DHCP Relays.

> DHCP-relay does provide some functionality not

It's more than just "functionality". IP addressing is a utility-class
service. That's why there's lots of demand for clustering, redundancy,
etc. Reliable operation is not just a good idea -- it's a requirement in
many situations. MODECFG isn't designed to provide highly reliable
addressing functionalty -- or to evolve so as to support future needs.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 1 Feb 2003 18:10:16 -0800 (PST)

Maybe it's just me, but I don't understand the plan for support of IPv6 in
MODECFG.

So far, the available ways of getting an IPv6 address are static config,
RS/RA or DHCPv6. The former doesn't need MODECFG, and the latter two
mechanisms would ordinarily require a tunneling solution somewhat akin to
RFC 3456.

But if MODECFG is used instead, it would be nice to understand how it's
supposed to work. Some questions:

a. Does MODECFG assign a specific IPv6 address, as DHCPv6 can do? Or does
it provide only a prefix as in RS/RA?

b. How would MODECFG handle the other functions of RS/RA, such as the "H"
bit for a MIPv6 HA? If MODECFG doesn't handle those functions, how much of
the IPv6 functionality do we lose? If it does handle them, do we end up
duplicating the RS/RA functionality in MODECFG?

c. How does MODECFG handle both IPv4 and IPv6 configuration? Do we need
both IPv4 and IPv6 config support in MODECFG?

d. Or is it assumed that MODECFG will only handle IPv4 address and config,
and that IPv6 will be handled by tunneling as in RFC 3456? If it is
already necessary to support tunneling of RS/RA and DHCPv6 in order to
support IPv6, why support MODECFG in addition?

---

From: [email-masked]
Date: Sat, 1 Feb 2003 23:10:19 -0500

> the operation of a DHCP Relay with a DHCP proxy -- which *is*
ill-defined.

OK... bear with me. I just reread RFC 2131 and still don't get it.

When an IPsec gateway is acting as a DHCP Relay, I can almost see how it
forwards the DHCP packets in a stateless fashion (it seems like it has to
hold state between the request and response, but could be stateless the
rest of the time). But there is a second function of the gateway that is
intimately bound to address allocation. The IPsec gateway has to respond to
ARPs to the assigned IP address and forward packets addressed to that IP
address to the endnode. How does it know when to start and stop doing that?
It can't just trust the endnode to tell it... that would allow someone
connecting in to seize IP addresses belonging to someone else. It seems
like it has to keep track of the interaction between the endnode and the
DHCP server including keeping track of lease expiration and renewal.

What am I missing?

          --Charlie

---

From: [email-masked]
Date: Sat, 1 Feb 2003 23:32:16 -0500

> Maybe it's just me, but I don't understand the plan for support of IPv6
in
I'm just the transcriber of MODECFG. I believe I understand what it says,
but I don't know what special challenges are present with IPv6 that might
cause problems.

> it provide only a prefix as in RS/RA?
Currently, the spec says that the host requests an IPv6 address and the
IPsec gateway returns one. It provides the entire address, not a prefix.
Is that a problem?

> duplicating the RS/RA functionality in MODECFG?

I don't believe MODECFG addresses these.
If they are needed and transparent to IPsec,
that would argue for tunnelling DHCP as you propose. If IPsec needs to
know about them to set its forwarding tables, both protocols are in
trouble.

> both IPv4 and IPv6 config support in MODECFG?

Currently, the spec says that the host MUST request either an IPv4 or IPv6
address and MAY request both. Is that sufficient?

> support IPv6, why support MODECFG in addition?

The reason to support MODECFG in addition (in my opinion) is to have a
simple
protocol for negotiating both an address lease and network access over that
address. Without it, the minimum interaction to set up an ESP SA is *many*
more messages... I don't even know how many. I would guess at least 12 vs.
the current 6.

          --Charlie

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 1 Feb 2003 19:54:30 -0800 (PST)

> But there is a second function of the gateway that is
> address to the endnode.

So you're saying that the IPsec gateway *must* implement proxy ARP? Why
wouldn't participation in the routing mesh be enough? For example, if the
IPsec gateway is injecting routes for the addresses of the nodes it is
handling (either an aggregated prefix or the host routes) wouldn't that
work? The result will be that packets destined for those addresses will be
forwarded to the IPsec gateway.

> How does it know when to start and stop doing that?

I think that is a function of how reachability is determined -- which is
the same for either proposal, no?

> connecting in to seize IP addresses belonging to someone else.

As noted in RFC 3456:

   As described in [17], a number of issues arise when forwarding DHCP
   client requests from untrusted sources.  These include DHCP
   exhaustion attacks, and spoofing of the client identifier option or
   client MAC address.  These issues can be partially addressed through
   use of the DHCP Relay Information Option [17].

> DHCP server including keeping track of lease expiration and renewal.

I think you're missing the DHCP Relay Information option [RFC3046], which
enables the Relay to deal with these issues while remaining stateless.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 1 Feb 2003 21:39:25 -0800 (PST)

> IPsec gateway returns one. It provides the entire address, not a prefix.

It might be. What if the client wants to announce a prefix to its own
network? If the client obtains a single IPv4 address, then it can use 6to4
and obtain a suitable IPv6 prefix to announce. So it seems reasonable to
be able to obtain an IPv6 prefix for the same purpose, assuming that the
negotiated selectors permit it.

> know about them to set its forwarding tables, both protocols are in

Prefix assignment will definitely affect the routing table. If the gateway
assigns a different prefix to each tunnel, then routing is fairly
straightforward. This could be handled, for example, by assigning a /48 to
the gateway -- then there are enough /64s for 65K tunnels. However, if
the gateway obtains a single prefix, and tries to share this among
multiple tunnels, then it will need to plumb host routes, not only for
the clients, but also for the hosts behind the clients. This becomes
complex.

As for the effects of eliminating IPv6 RS/RA, I think we will need to
think about this carefully, because this serves multiple purposes. Perhaps
it might make sense to ask the question of the IPv6 WG chair Margaret
Wasserman.

> address and MAY request both. Is that sufficient?

My question was more about configuration than addressing (which is
discussed above).

> simple protocol for negotiating both an address lease and network access
> over that address.

I think we both agree that the issue is about address assignment, *not*
configuration. If we're going to be creating a configuration scheme we
hope to live with for a long time, it's probably best not to pick an
approach that requires a disclaimer: "I wouldn't design it this way
myself, but..."

If one assumes that the IPsec gateway is assigned a prefix
to allocate out of, over which it has complete control (as opposed to
having to go to a DHCPv4 server for addresses), then I think that IPv4
address assignment via MODECFG can be made to work. In that case,
there is no need for DHCP authentication, or address renewal (since the
gateway is assumed to own the prefix it allocates out of in perpetuity).
If those are the assumptions, it would be good to document them clearly.

However, I have my doubts about whether this approach is sound for IPv6,
or whether there aren't some unforseen effects (like affecting our
ability to put a Home Agent and IPsec gateway on the same box). We've
already learned recently that IKEv2 has some undesirable mobility
properties (Francis Dupont and Jari Arkko are preparing mail on this), so
some more thought is needed.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 02 Feb 2003 18:13:49 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:

    Bernard> So you're saying that the IPsec gateway *must* implement proxy ARP? Why
    Bernard> wouldn't participation in the routing mesh be enough? For example, if the
    Bernard> IPsec gateway is injecting routes for the addresses of the nodes it is

  In the smallest sites, proxy-ARP is the way to go.
  In a medium size site, one may be able to arrange to statically route a
block of addresses at the VPN gateway. (There being, otherwise, no "routing mesh")
  In a larger site, some kind of dynamic routing, perhaps injecting /32
routes (/128 routes) into OSPF or ISIS is the way to go.

  There is an issue with releasing of the proxy-ARP. I've personally
experienced this problem, independantly of being auto-configured (I was
statically at the same IP inside and out). 

  The VPN gateway, once it sees an ARP reply for an IP that it is
proxy-ARP'ing, needs to do some kind of keepalive with the client. If it
turns out the client is dead, then it should drop this connection. This isn't
very solid - but this is why many point out that having seperate address
pools is a necessary.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: "Darren Dukes" <[email-masked]>
Date: Mon, 3 Feb 2003 02:13:06 -0500

> [email-masked]
>

The idea is that MODECFG will work the same for v6 as v4.  It will be used
to assign an address, and optionally the other attributes defined, to the
IRAC.  I have very limited understanding of RS/RA and DHCPv6, but I think
RA's _should_ be handled as any other host would, and DHCPv6
INFORMATION-REQUEST could be used for additional DHCPv6 options.

> > duplicating the RS/RA functionality in MODECFG?

As I said above, I know little about the specifics of RS/RA, but I don't
think we'll be loosing anything since an IRAC _should_ be receiving and
processing RAs (H-bit included) as any other node would be once an address
is assigned to it and it's created Child-SA(s).  Can anyone confirm this?

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Feb 2003 04:03:22 -0800 (PST)

> INFORMATION-REQUEST could be used for additional DHCPv6 options.

The problem is that the IPv6 and IPv4 addressing architectures are quite
different.

> is assigned to it and it's created Child-SA(s).  Can anyone confirm this?

I think there are some implications to having the client obtain
addresses in two ways -- multiple addresses from the RS/RA assigned
prefixes, one from MODECFG. For example, I don't think that this process
will be faster -- because you'll be unable to do optimistic DAD on the
MODECFG assigned address. And if the RS/RA assigned prefix is the same as
the prefix for the MODECFG assigned address, then it is possible for there
to be conflicts between the two approaches -- and it is not clear to me
how they are resolved. So some careful thinking is probably required to
understand the implications of this.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 3 Feb 2003 16:55:30 -0500

>forwarded to the IPsec gateway.

Bernard,

When one starts moving into this realm of routing functionality, 
there are serious security concerns that IPsec has not yet fully 
addressed.

In 2401bis, we plan on de-coupling route selection from SA selection, 
by having an explicit lookup for routing performed prior to SA 
selection, and then passing along a virtual interface ID as part of 
the SA selection process.  This is something that was discussed among 
a set of folks interested in PPVPN and overlay nets over the last 
several months. If adopted, this would make it easier to accommodate 
the sort of full-fledged routing participation that you allude to.

However, another problem arises here, i.e., how do we know what 
portions of address space a given IPsec gateway is authorized to 
advertise. If the gateway represents a leaf for routing purposes, 
then this may be successfully managed manually, and with the current 
binding of SA selection and routing, I assume this is what has been 
done. But there are folks who have a good reason to want to separate 
these two functions, and if we start having IPsec gateways executing 
BGP, I worry that we do not have adequate means to verify the 
authorization aspect of routes.  The infrastructure developed for 
S-BGP (a pet project of mine) would supply the necessary info, but it 
has not been deployed so far. At a minimum we should address the 
question in our documents, even if we don't have an agreed-upon 
solution.

Steve

---

From: Bora Akyol <[email-masked]>
Date: Mon, 03 Feb 2003 17:41:42 -0800

At 04:55 PM 2/3/2003 -0500, Stephen Kent wrote:
>In 2401bis, we plan on de-coupling route selection from SA selection, by 
>having an explicit lookup for routing performed prior to SA selection, and 
>then passing along a virtual interface ID as part of the SA selection 
>process.  This is something that was discussed among a set of folks 
>interested in PPVPN and overlay nets over the last several months. If 
>adopted, this would make it easier to accommodate the sort of full-fledged 
>routing participation that you allude to.

I fear that this is straying from the scope of the ipsec working group to 
something much larger. As you point out there is no infra-structure in the 
Internet to verify that either a route or its advertiser are authentic. 
Specification of a virtual interface ID is implementation specific.

I want to understand more of the concern here. Is the concern that ipsec 
SAs are being used to route traffic or due to the uncontrolled routing, 
some packets that should be secured are going in the clear due to the wrong 
interface selection?

Can you please elaborate the reasoning behind this concern and verbiage?

Thanks

Bora

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Feb 2003 21:01:35 -0500

At 5:41 PM -0800 2/3/03, Bora Akyol wrote:
>>In 2401bis, we plan on de-coupling route selection from SA 
>>selection, by having an explicit lookup for routing performed prior 
>>to SA selection, and then passing along a virtual interface ID as 
>>part of the SA selection process.  This is something that was 
>>discussed among a set of folks interested in PPVPN and overlay nets 
>>over the last several months. If adopted, this would make it easier 
>>to accommodate the sort of full-fledged routing participation that 
>>you allude to.
>
>
>I fear that this is straying from the scope of the ipsec working 
>group to something much larger. As you point out there is no 
>infra-structure in the Internet to verify that either a route or its 
>advertiser are authentic. Specification of a virtual interface ID is 
>implementation specific.
>
>I want to understand more of the concern here. Is the concern that 
>ipsec SAs are being used to route traffic or due to the uncontrolled 
>routing, some packets that should be secured are going in the clear 
>due to the wrong interface selection?
>

Bora,

IPsec provides access controls based on packet headers, primarily S/D 
IP addresses. If an IPsec implementation serves a single host, we can 
manage this well, i.e., we can appropriately configure the SPD to 
reflect the address of the host. If an IPsec gateway serves a subnet 
we can probably do an acceptable job as well. But, if people start 
thinking in terms of routing through a subnet protected with an IPsec 
security gateway, en route to some other subnet, this sort of transit 
traffic protection creates new requirements for secure management of 
the binding between an IPsec device and the addresses that it is 
authorized to represent. I agree that this is a bigger issue than 
IPsec, but we need to be cognizant of vulnerabilities that will 
result if we say that IPsec gateways can be used for this sort of 
transit traffic protection.  We need to advise potential users of the 
technology of these vulnerabilities, and suggest means by which the 
vulnerabilities can  be mitigated.

Steve