Subject: Re: [dhcwg] dhc wg last call on vpn-option and agent-vpn-id drafts

From: Kim Kinnear <[email-masked]>
Date: Mon, 17 Sep 2007 17:07:37 -0400

David,

I'm revising the vpn-id option-82 sub-option draft, and I had
some questions about your comments on it during the last call....

At 03:54 PM 7/22/2007, David W. Hankins wrote:
>On Tue, Jul 10, 2007 at 03:08:58PM +0200, Stig Venaas wrote:
>> Virtual Subnet Selection Option <draft-ietf-dhc-vpn-option-06.txt>
>
>Noting that Bernie has many fine points I will try not to repeat,
>
>   All other values of the type field are invalid as of this memo and
>   VSS options containing any other value than zero (0) or one (1)
>   SHOULD be ignored.
>
>We want old software to work with new protocol work, should there
>ever be a document to assign new type codes.  So I don't understand
>the motivation here to cause it to be ignored.  It's your existing
>usage, I'm just curious why this was selected rather than allowing
>operators to specify the contents by hand or such.
>
>I would suggest simply removing this paragraph if it is not actually
>documenting a current practice (in which case everyone really SHOULD
>do more or less the same thing).

        They way I've always done this (and I didn't invent it)
        is that the draft that defines the first several items in
        a list says that those are all the legal values.  Then
        any other draft that extends the list is, by definition,
        revising that existing draft as far as the list of
        acceptable values is concerned.  I'll try to put in some
        language making that more clear, but this certainly isn't
        the first time I've done this (or seen it done).

>The Security section says:
>
>   This option SHOULD NOT be used without also making use of the DHCP
>   Authentication option [5].
>
>But also says:
>
>   DHCP relays MAY choose to remove the option before passing on
>   DHCPDISCOVER packets.
>
>I'm kind of confused.  You should use authentication, but relays MAY
>break authentication by altering the client area of the packet?

        Well, the authentication is a "MAY", so they might not use
        it...

>If a relay strips this option, doesn't that just cause the client to
>ignore the server (since it won't contain this option in its reply)?
>Why not just drop the packet then?

        That's actually better approach, I think.

>I wonder if this option is used to assign overlapping address spaces
>to different VPN's.  In that case, I wonder if it should contain
>(even if there is no current practice) DHCPLEASEQUERY language, to
>disambiguate queries.

        I'm missing what you are asking for here.  Certainly this
        option can be used in a DHCPLEASEQUERY message, but I
        don't see any reason to mention that (particularly).  But
        there is something else you are looking for --
        DHCPLEASEQUERY "language", and I don't know what you are
        looking for here.

>Or I think possibly it should explicitly mention that the current
>usage is not DHCPLEASEQUERY compatible?

        It is quite leasequery compatible.

>> Virtual Subnet Selection Sub-Option for the Relay Agent Information 
>> Option for DHCPv4 <draft-ietf-dhc-agent-vpn-id-04.txt>
>
>I think the security section was cut and paste from the client
>option.  It doesn't make sense to restrict relay processing to
>specific clients served by that relay in this context.

        I've read this statement about 10 times and I still don't
        see what you were driving at -- HELP!

        Thanks much for the clarifcations!

        Regards -- Kim

>> The last call will conclude at 1700EST on Sun, 2007-07-22.
>
>Yes!  Under the wire!
>
>-- 
>Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
>Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/
>-- 
>David W. Hankins        "If you don't do it right the first time,
>Software Engineer                    you'll just have to do it again."
>Internet Systems Consortium, Inc.               -- Jack T. Hankins
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 18 Sep 2007 10:35:49 +0300

Hello,

I recently discovered this I-D and now I just realized I missed the WG LC. I
hope it is not too late, but I have a comment.

   Servers configured to support this option MUST return an identical
   copy of the option to any client that sends it, regardless of whether
   or not the client requests the option in a parameter request list.
   Clients using this option MUST discard DHCPOFFER or DHCPACK packets
   that do not contain this option.

Do we really need the second MUST? I'm thinking if the client is willing to
use the DHCP server despite the lack of VPN support, it should be able to do
that, based on some local policy. Can we downgrade that MUST to a MAY?

Alper

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 27 Sep 2007 11:53:40 -0700

>         the first time I've done this (or seen it done).

Don't bother, I was thinking for some reason 'drop the packet' rather
than 'ignore the option within the packet'.  Can't explain why.

>         Well, the authentication is a "MAY", so they might not use

I think I'm also more than a little uncomfortable with the idea of
relay agents changing/reducing/increasing the number of client
supplied options.

If there were a relay agent scoped option the relay could use to
inform a server in preference to any client supplied value so that
the client scoped value was ignored...

But I think a bit later in the discussion I suddenly realized that
this was an RFC3942 related document and moving to Informational, that
is it exists to describe existing usage?

I don't really have a complaint in that case.

>         I'm missing what you are asking for here.  Certainly this

Wow, was that ever cryptic of me.  I just figured it out (again), let
me explain where my head was;

It ocurred to me at this point in reading the draft that this
option may be used where one subnet (let us imagine 10.0/24) was
on different VLANs.

Not one contiguous 10.0/24 spread across broadcast domains in some
crazy way, but "several copies" of 10.0/24, such that two clients on
different VLANs can have the same address, 10.0.0.1.

Meaning that the VLAN ID would be used to discriminate from which
pool of 10.0/24's the client would be allocated a unique-to-that-VLAN
address.

In this case, DHCPLEASEQUERY by IP address would need to be extended
in order to limit the search to a VLAN, yes?

I think we have no terminology for any of this, so hopefully the
above 'crayon scrawl' of words helps somewhat explain where my head
was?  Maybe if we want to invent terminology for this we should call
it "DHCP Views" since 'views' already have a fabulous reputation for
being the manifestation of true evil.

My concern stems not insubstantially from multiple requests we get on
dhcp-users when they can't figure out how to do precisely this sort
of thing, by the way.  'walled garden' networks in multiple locations
across the country all served by a common DHCP server, which doesn't
(and can't really) know they're in different broadcast domains.

>         It is quite leasequery compatible.

I think that if that is the case, then my concern above can not be
true, and so there is no issue.

>         see what you were driving at -- HELP!

I can't believe I didn't quote context on that comment.

Can you mail me the vpn-id draft?  It seems to have expired!

Sorry for the delay Kim.

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 27 Sep 2007 15:45:41 -0400

>is it exists to describe existing usage?

        Actually, no.  We are intending this to be standards
        track.  There is some existing usage and this doesn't
        at present conflict with the existing usage -- though
        that (of course) may always change.

>pool of 10.0/24's the client would be allocated a unique-to-that-VLAN

        Yes, exactly.

>in order to limit the search to a VLAN, yes?

        Yes, and that is why there is both a relay-agent
        sub-option vpn-id as well as a "top level" option vpn-id.
        The top-level option vpn-id would be used in the
        leasequery.

        I'll mention that this is how you would do a leasequery
        -- use the vpn-id option.

>true, and so there is no issue.

        I think there is no issue, then, since this all works
        great with leasequery.

        Thanks again for getting back to me -- Kim

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 27 Sep 2007 12:57:42 -0700

>         that (of course) may always change.

In that case I either don't understand, or don't agree with, the
mechanic where a client-supplied value is overriden by the relay
agent through its selective omission, rather than though server
processing.

Surely the server could just ignore such a value and select the
relay agent supplied value?

We have enough existing problems with relay agents and client
authentication...

Well, it's something to think about.

> >pool of 10.0/24's the client would be allocated a unique-to-that-VLAN

The nice thing about living in a world where Pandora's box has
already been opened is that there is no hope left to loose.

I was really hoping we'd never see 'views' in DHCP, but I admit their
operational necessity readily.

I can't think of anything specific to reinforce or restate, but I
only came to that conclusion some time after reading the document,
so it never quite 'popped out' at me.  Just some feedback.

>         -- use the vpn-id option.

That's fine, and it's all I meant; for a server to comply with this
option it needs to extend leasequery if it supports that message.  A
reminder to those ends helps ease implementation.

I'm looking over the vpn-id.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 27 Sep 2007 13:14:38 -0700

> >>         see what you were driving at -- HELP!

By 'cut and paste', I was referring to the RFC3118 citation, which
doesn't really make sense from a relay agent information option
point of view.  Is the relay agent going to authenticate clients?

For the unusual restriction, I think I was building on that, as the
suggested mechanism to counter 'faux relay agents', which is to drop
any packet containing relay agent information rather than the normally
prescribed "update giaddr and forward without changing the relay agent
option" from RFC3046, didn't make sense to me.  This sounds like a
general direction that may not be safe in general purpose networks?

Here's the context finally:

   The virtual-subnet-selection sub-option could be used by a client in
   order to obtain an IP address from a VPN other than the one on which
   it resides.  This attack can be partially prevented by the relay
   agent not forwarding any DHCP packet which already contains a relay-
   agent-information option.

Philosophically, I prefer letting the server sort it out, and would
suggest for example RFC4030 rather than selective omission.  That is,
the "simple" relay forwards the packets anyway, and the "complicated"
server keeps all the spaghetti in one bowl, and does whatever its
operator has told it to using whatever it can get from the packet
as context...RFC4030, giaddr or source IP address (combined with
strict remote and local firewalls), or whatever.

Since RFC4030 is no more adopted than RFC3118, I admit you probably
need to mention other tactics, but I think 4030 should be preferred
over what is essentially an update to the relay agent info option
that may not be safe in other contexts.

This'll teach me for trying to get comments out in a hurry.

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 27 Sep 2007 16:45:23 -0400

>relay agent supplied value?

        Sure, we already say that.  I'll remove this other text.

>We have enough existing problems with relay agents and client

        I couldn't agree more!

        Thanks -- Kim

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 27 Sep 2007 16:49:42 -0400

>strict remote and local firewalls), or whatever.

        That makes sense to me.  I'll leave out the words on not
        forwarding stuff, and suggest that the place to sort it
        out is the DHCP server.  I'll also reference RFC4030.

        Thanks much -- Kim