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

From: Alfred Hönes <[email-masked]>
Date: Tue, 23 Dec 2008 22:02:38 +0100 (MEZ)

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

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.

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:  [email-masked]                     |
+------------------------+--------------------------------------------+

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