Subject: Re: [dhcwg] draft-ietf-dhc-vpn-option-09 issue with sub-option bouncing

From: Kim Kinnear <[email-masked]>
Date: Wed, 07 Jan 2009 21:08:33 -0500

At 04:02 PM 12/23/2008, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:

>I have reviewed draft-ietf-dhc-vpn-option-09 and already sent
>off-list a couple of editorial notes.

        Yes, thank you for those.  When I next revise the draft,
        I'll include these editorial changes.

>However, I see one significant issue not satisfactorily resolved
>in the current draft version.
>Below, I recall the problem and propose a mechanism to mitigate it.
>
>As explained in various places in the draft (in particular
>Section 7.2), in the DHPCv4 case the utility of the VSS sub-option
>suffers from the default behavior of the server (per RFC 3046) of
>blindly bouncing unknown sub-options of the Realy-Agent-Information
>option.  This way, the DHCP relay originally sending the sub-option
>in the request can not conclude from the sub-option in the reply
>whether the server has not understood the VSS sub-option and simply
>bounced it or it has understood the VSS sub-option and confirmed
>the value sent in the request by echoing the unchanged VSS sub-
>option.
>
>That seems to be a significant drawback.

        Yes and no.  The case that is hard to distinguish is the
        case where the DHCP server doesn't support the VSS option
        but the relay agent expects that it does.

        As stated in the draft:

>   The current use of the VSS option and sub-option require that each
>   entity knows the part that it plays in dealing with VPN data.  Each
>   entity -- client, relay agent or agents, and server -- SHOULD know
>   through some policy or configuration beyond the scope of this
>   document whether it is responsible for specifying VPN information
>   using the VSS option or sub-option or responsible for responding to
>   VSS information specified by another entity, or simply ignoring any
>   VSS information which it might see.

        Perhaps we could extend this to include a statement that
        not only SHOULD the entities know their respective roles
        regarding the VSS option/information, but that they
        SHOULD also be capable of supporting the processing
        required by the role they are playing.  I'd be up for
        that, though I think it is kind of implied.

        The case that for which you have proposed a solution is
        one where the DHCP server doesn't understand the VSS
        option and therefore doesn't process it at all.  This is
        a total configuration screwup, not something that can
        happen on one packet and not happen on the next packet.
        This will never work.

        So, "yes", it is a drawback that the relay agent can't
        tell if the server supports VSS processing from the
        contents of one packet.  But it is important to
        understand that the entire processing of these
        options/sub-options requires configuration correspondence
        well outside of the bounds of what is documented in this
        draft (and the draft make that point more than once).

        Having a DHCP server that supports the VSS option
        installed if you are going to configure your relay agents
        to support VSS processing is just one more part of the
        configuration correspondence that is required, and not
        the largest part by any means.

        My point is that I believe the particular issue which you
        have focused looks like it is significant if you look
        just at this one issue, but if you stand back a bit I
        think that it isn't actually an operational problem of
        significance given the other things you have to get right
        to put together a working system which incorporates VSS
        option processing.  Another way to put this is to say
        that solving this one problem will make it only
        fractionally easier in the field to configure these
        systems.

        So, personally, I believe that the draft is acceptable as
        it stands.  Although I'd gladly add words about this
        issue and the requirement to have a DHCP server that
        supports VSS option processing if you are going to
        configure such processing on your relay agents.  This
        would be easy, but not what you are advocating.

        That said, what you have proposed below would indeed
        solve this problem.  I feel it is a relatively large
        amount of mechanism given the scope of the problem it is
        designed to solve.  However, it would work and could be
        included into the draft if there is a general consensus
        that this is the right approach.

        I'll be looking for input from other folks to see if we
        have that general consensus for the changes that you have
        proposed.

        A number of other folks have found the draft to be
        acceptable as-is, and indeed this particular problem was
        brought up by David Hankins in the past and the solution
        that is embodied in the draft at this point satisfied his
        previous objections.

        Not least, this draft has been through last call after
        last call, and if we make this change we may need to go
        through yet another last call.  This prospect leaves me
        less than thrilled, as I'm sure you can understand, but
        getting it right (or at least right enough) is certainly
        more important.

        Thanks for reading the draft.

        Regards -- Kim

>After some consideration of the problem, it becomes apparent that
>it depends on the VSS type whether or not this is a real issue.
>In the "global/default VPN" case (VSS type 255), it looks like
>the realy agent would not gain anything from being able to
>distinguish the two cases; that apparently only matters for the
>VSS types 0 and 1 (or any possible future 'concrete' values).
>
>This has guided me to envision modified encoding and processing
>rules of the VSS type -- see below.
>
>Due to lack of time, I have not tried to discover if this idea
>already has been considered in the past.  If so, and it has been
>rejected, I apologize for bringing it up again.
>
>a)  Encoding:
>
> VSS types 127..254 are permanently forbidden for VSS information
> in the DHVPv4/v6 VSS options and the v4 VSS sub-option in a
> message to the server.
>
> For the VSS sub-option in a response, the following additional
> values are defined:
>
>     128   same as 0, but "confirmed by server"
>     129   same as 1, but "confirmed by server"
>
>b) Server Processing
>
>A DHCPv4 server that understands the VSS sub-option (and supports
>this advanced encoding) sets the MSB in the VSS type when it copies
>the sub-option to the response "unchanged" per the current draft.
>Note that this is an idempotent operation on the 'global' VSS type
>value, leaving it unchanged for improved interoperability with
>existing implementations.
>
>TBD: It needs to be figured out whether it might be preferable
>    (yet less backwards compatible) to also set the MSB when the
>    server *changes* the VS type in the VSS sub-option to be sent
>    back to one of the 'concrete' values (currently 0 or 1).
>
>Note: This revised server behavior SHOULD be subject to activation
>     per configuration, with defaults to 'off'.
>
>c) Relay Agent Processing
>
>A DHCPv4 Relay Agent receiving one of the new VSS types in the
>VSS sub-option strips the MSB of the VSS type and performs the
>processing currently described in the draft, but it also notes that
>the server has confirmed the (proposed) value it had sent in the
>request, and can hence exclude all considerations and cautionary
>processing related to lack of distinction between the two cases.
>
>
>Kind regards,
> Alfred HÎnes.
>
>--  
>
>+------------------------ +--------------------------------------------+
>| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.- Phys.  |
>| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax:  
>-18         |
>| D-71254  Ditzingen     |  E-Mail:  ah@TR- Sys.de                     |
>+------------------------ +--------------------------------------------+

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

---

From: Kim Kinnear <[email-masked]>
Date: Tue, 27 Jan 2009 15:02:28 -0500

Alfred, others on the dhcwg list,

Alfred, I have responded to your substantive (as opposed to
editorial) concern about the current version of the vpn-option
draft (09).  See below for details.  The short story is that I
believe the draft is acceptable as it stands, particularly since
David Hankins raised an issue very similar if not identical to
this in the past and we revised to draft to acceptably meet his
objections.

However, I have agreed to put some words into the draft to ensure
that people understand the need to have a server which supports
the VSS option if they configure their relay agents to use the
VSS option.  This might help mitigate the concern you have,
though it is less than you proposed.

As your proposal includes a considerable addition to the
mechanism of the VSS option, I was looking for other support for
your proposal from the list.  I have not heard anyone who agreed
that what you propose is necessary, nor anyone who suggested that
it was not necessary.

I have also not heard back from you concerning your reaction to
my explanations and proposals, though it is possible that I have
missed your email, and if so, I certainly apologize.

So, I'm trying a second time to elicit some response from the
list as well as feedback from you.

Options:

        (a) Draft is acceptable as is.

        (b) Add more words to ensure that people know that they 
            need to use a DHCP server which supports VSS options
            if they configure VSS options in a relay agent.

        (c) Implement Alfred's proposal to define a new range of
            type bytes and specify how they are used so that a
            relay agent knows for sure whether a DHCP server
            supports the VSS option when it is used.

Thanks all -- Kim