Subject: [Gen-art] Gen-art telechat review of draft-ietf-savi-dhcp-32

From: Elwyn Davies <[email-masked]>
Date: Sun, 01 Feb 2015 00:31:00 +0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-savi-dhcp-32.txt
Reviewer: Elwyn Davies
Review Date:  2015/01/30
IETF LC End Date: [2014/08/07]
IESG Telechat date: 2015/02/05

Summary:
I regret to say that although the draft has considerably improved since 
I last reviewed it, there are still a number of significant issues that 
need to be addressed before it can be considered ready for the IESG.  My 
main concern for the technical quality of the document is the 
specification of the Data Snooping Process where the state machine is 
just not properly specified.  There are numerous more local problems.  I 
am unsure how significant the issue with temporary disconnections if the 
data snooping process has to be used repeatedly on a particular 
attachment point.  The various suggestions on limiting the rate of data 
snooping and the probabilistic back off may mean that the disconnection 
disrupts connections, whereas if the disconnection are only a couple of 
packets long, the usual congestion avoidance mechanisms will cover up 
the gap.  Likewise, in the likely deployment scenarios of SAVI-DHCP, 
fragmented DHCP messages may be a non-problem: However the issue should 
be noted.  Previous reviews have noted that the attribute setting 
requirements could be contradictory; this has not been fixed, although I 
think the points of conflict have moved.  I have suggested some text to 
cover the necessity for security protection of lease query transactions 
which were also noted previously.

Major issues:
===========
None

Minor issues:
===========
Temporary disconnections when Data Snooping Process is relevant:
-----------------------------------------------------------------------------------------
The intention in the Data Snooping process appears to be that when the 
state reaches BOUND, the state machine 'merges' with the DHCP Snooping 
Process machine and thereafter responds to snooped DHCP messages as if 
the BOUND state had been reached purely by snooping DHCP messages.

However, there is no guarantee, in the exceptional cases where the Data 
Snooping Process is invoked in the first place, that the SAVI device 
will 'see' any relevant DHCP messages after reaching the BOUND state 
since the lack of such messages is what triggered the Data Snooping 
Process in the first place.  Consequently, there is a significant 
likelihood that when the lease time (derived via lease querying) 
expires, the SAVI device won't have seen any of the DHCP messages that 
would indicate that the lease had been extended.   The timeout event 
will therefore trigger the removal of the SAVI binding.  Thereafter the 
messages from the attached device will be dropped at least until the 
Data Snooping Process can kick in again, assuming that the attached 
device still has a lease and the SAVI device is still not seeing the 
DHCP messages.

This will mean that a device managed exclusively by Data Snooping will 
suffer periodic packet loss.  How much of an effect this will have on 
the attached device depends on the probabilistic process used to start 
the Data Snooping Process and the applications being run on it.  If only 
a couple of packets are lost then the disconnection will probably be no 
worse than the effects of temporary congestion and the user will likely 
be unaware.  Longer outages could be very irritating, depending on their 
frequency, and would be difficult to diagnose/explain to the user.

One possibility would be to remember that a binding anchor was initially 
set up by data snooping and turn up the Data Snooping Probability to one 
for a period after its lease timed out.  This would minimise the 
disconnection period at the expense of a little more complexity.

Note, also that if not all the packets go through the SAVI device, those 
not passing through will not be validated and could have spoofed source 
addresses.

I think these issues should be mentioned even if it is thought they do 
not need any action.

Fragmented DHCP messages:
---------------------------------------
The brief mention of draft-ietf-opsec-dhcpv6-shield at the end of s4.2.2 
triggered a thought about a potential problem for SAVI-DHCP that doesn't 
seem to be considered in the draft.  It is possible that the DHCP 
messages that savi-dhcp has to snoop on might be fragmented before they 
pass through the SAVI device.  Unlike the scenario in the "shield" 
draft, it is not sufficient for the SAVI device to consider only the 
first fragment in a v6 DHCP message as it needs to know what type of 
DHCP message is passing by and that is not guaranteed to be deducible 
from the first fragment.  It may well not be a frequent occurrence, but 
it should probably be brought out - AFAICS it can apply to both DHCPv4 
and DHCPv6 - it seems likely that the SAVI device would have to 
defragment the DHCP message in order to analyse it, but I haven't looked 
into this in detail.

s4.1, para 3:
>   Traffic from unprotected links should be
>     checked by an unprotected system or [RFC2827  <http://tools.ietf.org/html/rfc2827>] mechanisms.
What does "an unprotected system" imply?  Does "system" mean a (SAVI) 
technique and devices other than the DHCP scheme or just a device 
outside the protection perimeter.   I would have assumed that the 
protection scheme could also be implemented on the (DHCP) SAVI device in 
parallel with the DHCP scheme.  Some different words are needed but I am 
not sure what.

s4.2.3:
> If it
>     is FALSE, either the Trust attribute must be TRUE (so that bindings
>     become irrelevant) or another SAVI mechanism such as SAVI-FCFS must
>     be used on the point of attachment.
Does the protection mechanism *have* to be another SAVI mechanism? Would 
RFC 2827 not be an alternative?

s4.2.3 (DHCP-Snooping Attribute)/s4.2.4 (Data-Snooping 
Attribute)/s4.2.5(Validating Attribute):
Last para of s4.2.3:

    Whenever this attribute is set TRUE on a point of attachment, the
    "Validating Attribute" MUST also be set TRUE.

Last para sf s4.2.4:
    Whenever this attribute is set on an attachment, the "Validating
    Attribute" MUST be set on the same attachment.

Last para of s4.2.5:

    The expected use case is when SAVI is used to monitor but not block
    unvalidated transmissions.  The network manager, in that case, may
    set the DHCP-Snooping and/or Data-Snooping attribute TRUE but the
    VALIDATING attribute FALSE.

These statements are inconsistent:
- s4.2.3 says DHCP-Snooping == TRUE  => Validating == TRUE
- s4.2.3 says Data-Snooping == TRUE  => Validating == TRUE
- s4.2.5 says DHCP=Snooping == TRUE and/or Data-Snooping == TRUE allows
   VALIDATING to be TRUE or FALSE.

I believe the statements in s4.2.3 and s4.2.4 can be deleted.

s4.2.4, last para:
> Since some networks
>     require DHCP deployment and others avoid it, there is no obvious
>     universal default value for the Data-Snooping Attribute.  However,
>     note that deployment of SLAAC (and therefore SAVI-FCFS) is generally
>     configuration-free, while the deployment of DHCP involves at minimum
>     the deployment of a server.  Hence, the Data-Snooping Attribute
>     should default to FALSE, and a mechanism should be implemented to
>     conveniently set it to TRUE on all points of attachment for which the
>     Trust attribute is FALSE.
If this text remains as it is the acronym SLAAC needs to be expanded 
(probably back in s1).  However, introducing SLAAC at this point seems 
inappropriate.  SAVI-DHCP is specifically stated in s1 to be intended 
for 'pure DHCP scenarios'.  Further, it is not at all clear why the 
issue of zero-configuration or otherwise suddenly appears here.  I 
suggest that the second sentence is removed unless there is some really 
good reason that I have missed.

It seems to me that maybe there is something to be said about indirectly 
connected hosts here.

Nits/editorial comments:
General: Both 'validate' and 'check' are used in the text. 'Validating' 
(as in 'Validating Attribute') appears to have the specific meaning of 
ensuring that the IP source address is legitimate, whereas 'checking' 
has a variety of more general meanings.  It would be wise to ensure that 
wherever ensuring that the process of ensuring the IP source address is 
legitimate the term 'Validating' is used (possibly with a capital 
letter) and check is used in all other cases.

General: s/LEASEQUERY_REPLY/LEASEQUERY-REPLY/ (7 places) [There are also 
8 places where it is already right.]

s1, para 1, first sentence: (has two 'source's)
OLD:
    This document describes a fine-grained source IPv4 or IPv6 source
    address validation mechanism.
NEW:
    This document describes a fine-grained source
    address validation mechanism for IPv4 and IPv6 packets.

s1, para 1, sentence 4:
OLD:
assigned to the other attachment points or invalid in the network.
NEW:
assigned to any other attachment point in or not associated with the 
network.

s1, para 1, sentence 6: s/If [RFC2827]/Whereas [RFC2827]/

s1, para 2, sentence 2: s/the header of data packet/on the IP header of 
data packets/

s1, para 2, sentence 3: s/a permanent block/the permanent blockage/

s1, para 3:
OLD:
The appropriate SAVI method must be used in those cases.
NEW:
An alternative SAVI method would have be used in those cases.

s1, para 3: s/Besides, this mechanism/This mechanism/

s1, para 3: s/enable a SAVI solution for link-local/deploy an 
alternative SAVI solution for link-local/

s1, last para:
OLD:
This mechanism works for DHCPv4-only, DHCPv6-only, or both DHCPv4 and  
DHCPv6.
NEW:
This mechanism works for networks that use DHCPv4 only, DHCPv6 only, or 
both DHCPv4 and  DHCPv6.

s3, Client-Server messages, 6th bullet:  It would be good to distinguish 
this bullet for example making it a next level sub-list with no bullet.

s3, Direct attachment/Indirect attachment: s/e.g./i.e./ (one in each entry)

s3, Unprotected link/Protected link: I believe the intention is that 
these are links connected to SAVI devices. Hence: s/that the device/that 
the SAVI device/

s3, Cut Vertex: s/connected components/connected components in a 
(network) graph/

s3, Cut Vertex; s6.1, para 2; s7.1, 1st and 2nd  bullets:
s/DHCP snooping process[procedure]/DHCP Snooping Process/

s3, Detection message: "by the Data Snooping Process."  I think "by" 
should be "during" but  could be "that triggers".

s3: The various messages associated with the DHCP lease query process 
are not mentioned here.  It would probably be appropriate to add the 
DHCPv4 DHCPLEASEQUERY and DHCPv6 LEASEQUERY messages to the 
Client-Server set as they will occasionally be used by DHCP clients but 
are mostly used by SAVI devices in this context but should be allowed 
from clients.  On the other hand, it may be sensible to have a separate 
category for the lease query responses as treated specially on return 
flows - I am not quite sure which is best. However they are categorized 
they need to be filtered in the same way as Server-to-Client messages 
and only allowed on attachment points that have the Trust or DHCP-Trust 
attributes.

s4.1, para 1: I assume that a SAVI protection perimeter could contain 
more than one DHCP server (I think the last para of s4.2 implies this).  
In this case s/include a DHCP server/include at least one DHCP server/

s4.2.1, para 1:
> Examples of a trusted binding
>     anchor would be a port to another SAVI device,
Surely an attachment that is trusted doesn't have a binding anchor just 
because it is trusted - and also because, with multiple source addresses 
expected on the link, a binding anchor is not relevant. This is said in 
the second para of the section! I think s/trusted binding anchor/trusted 
attachment/.

s4.2.1, para 2:
Two points:
- Presumably the intention is that *no* messages from attached devices 
will be checked - singling out DHCP and 'data' messages is confusing - 
better something like 'any packets, including DHCP messages' would be 
better. Also I assume that 'checked' is a synonym for 'validated' here 
(see General point above)
- Para 1 of s4.2.6 states that "there is no need to set DHCP-Trust to 
TRUE on an attachment point that sets Trust TRUE   It would be clearer 
if this was made explicit here. I suggest:
OLD:
    SAVI devices will not set up bindings for points of attachment with
    the Trust attribute set TRUE; DHCP messages and data packets from
    attached devices with this attribute will not be checked.  If the
    DHCP Server-to-Client messages from attached devices with this
    attribute can trigger the state transitions specified in Section 6
    and Section 7, the corresponding processes in Section 6 and Section 7
    will handle these messages.
NEW:
    SAVI devices will not set up bindings for points of attachment with
    the Trust attribute set TRUE; no packets, including DHCP messages, from
    devices with this attribute on their attachments will be validated.  
However DHCP
    Server-to-Client messages will be snooped on attachment points with 
the Trust
    attribute set TRUE in the same way as if they had the DHCP-Trust 
attribute set (see
    Section 4.2.2)

s4.2.2: "ports that are trusted would have it set TRUE."
  As discussed in the previous comment Trust effectively implies 
DHCP-Trust.  Suggest changing this to:
NEW:
    attachment points that have Trust set TRUE are implicitly treated as 
if DHCP-Trust is TRUE.

s4.2.5, s8.1: s/VALIDATING/Validating/ (for consistency naming attributes)

s4.2.4, para 2: s/Data-Snooping process/Data Snooping Process/

s4.3.1, bullet #2: s/Each SAVI device only need/Each SAVI device only needs/

s4.3.1, last para: Add a sentence after sentence 1 to emphasise that 
incoming  DHCP Server-to-Client messages are filtered at the boundary.  
Suggest:
      DHCP server response messages incoming across the perimeter will 
be dropped
      (see Section 8).
[Note: This needs to be more general as the DHCP Server-to-Client 
messages do not include LEASEQUERY responses and maybe some others.]

s4.3.2, item (4)/Figure 1: The link to Non-SAVI Device 2 is marked as 
"protected" in Fig 1 and according to s4.3.2, item(4) it appears that 
the attachment point of this device on  SAVI Device A would have Trust 
set to TRUE.  I would have thought this meant  Non-SAVI Device 2 was 
inside the perimeter, but Fig 1 show it outside. Please explain what is 
going on, as some further text may be needed.

s4.3.2, last para:
OLD:
    The DHCP-Trust attribute is only TRUE on the inside links of the 
perimeter.
NEW:
    The DHCP-Trust attribute is only TRUE on links inside the perimeter.

s4.3.3, para 1: s/guideline/guidelines/

s4.3.5, para 1: s/and the SAVI switch/and the SAVI device/ (as it isn't 
necessarily a switch).

s4.3.5, para 2: s/IP spoofing traffic/spoofed IP traffic/

s4.4, item (1):
> Address configuration.  For DHCPv4: the client of a SAVI device
>         MUST have an IPv4 address.
Comparing this with the following words for IPv6, I think this ought to 
be "For DHCPv4: the SAVI device MUST have an IPv4 address." Otherwise it 
is really a non-sequitur, since if DHCPv4 is being used, presumably the 
idea is that the client will obtain an IPv4 address from the DHCP server 
- the text implies that it needs one even before it gets one via DHCPv4.

s4.4, item (2):  Add "A SAVI device may also require security 
parameters, such as pre-configured
keys to establish a secure connection for the Lease query process (see 
[RFC4388,RFC 5007]).
connection

s5, bullet #1: In the light of the discussion in s4.3.5:
OLD:

s5, bullet #2 in second set: s/data-snooping/data snooping/
OLD:
    o  Binding Anchor(Anchor): the binding anchor, i.e., a physical and/
       or link-layer property of the attachment.
NEW:
    o  Binding Anchor(Anchor): the binding anchor, i.e., one or more 
physical and/
       or link-layer properties of the attachment.

s5, Figure 4: s/instance/example/ (2 places - sentence before figure and 
caption of figure)

s6.1, sentence 1: s/on the client's point of attachment./via the 
client's point of attachment./

s6.1, sentence 2: s/basis/assumption/

s6.3: It would be worth noting here: "The DHCP message categories (e.g., 
DHCPv4 Discover) defined in Section 3 are used extensively in the 
definitions of events and elsewhere in the state machine definition."

s6.3: Possibly add equivalent text to that in s7.4:
> If an event will trigger the creation of a new binding entry, the 
> binding entry limit on the binding anchor MUST NOT be exceeded.

s6.3.2, EVE_DHCP_LEASEQUERY: It would be worth noting that DHCPv4 
DHCPLEASEQUERY is not used in the DHCP Snooping process to avoid 
confusion with s7.  Also since the LEASEQUERY should have been 
originated by the SAVI Device itself, the destination check should 
verify that the message is directed to this SAVI device  - and it should 
not be forwarded once it has been processed here.

s6.3.2:
>     o  Attribute check: ...; the DHCP Client-Server messages should be from
>        attachments with DHCP-Snooping attribute.
>     o  Destination check: the DHCP Server-to-Client messages should be
>        destined to attachments with DHCP-Snooping attribute.  ...
If I understand correctly, SAVI DHCP will allow devices on protected 
links (e.g., Non-SAVI device 2 in Figure 1) to obtain an IP address via 
DHCP without triggering the binding anchor set up.  The rules cited 
above would mean that the DHCP interactions for these devices would not 
trigger events, which I think is intended.  It might be worth making 
this explicit (assuming I have it correct). [Check: Should certain 
messages of types that might have triggered events but didn't, because 
of the above checks, be logged?]

s6.4.1.1: Two issues:
  - Refers to DHCPv4 Reboot.  This is not a message that triggers this 
event and so should not be mentioned.
  - Should the address in any IA's carried by the DHCPv6 Request message 
that can trigger this message also be copied into the BST? If so should 
it also refer to Figure 6?

s6.4.1.2:  Refers to DHCPv4 Request.  This is not a message that 
triggers this event and so should not be mentioned.

s6.4.1.3: Three issues:
  - Refers to DHCPv4 Request and DHCPv4 Reboot.  These are not messages 
that trigger this event and so should not be mentioned.
  - Should the address in any IA's carried by the DHCPv6 Solicitation 
message that can trigger this message also be copied into the BST? If so 
should it also refer to Figure 6?

s6.4.3.7: The LEASEQUERY message is destined for this SAVI device. It is 
not clear where it would be forwarded to (maybe some DHCPv6 
infrastructure on the SAVI device?)

Figure 9 Caption and Figure 10 Caption: s/Transit/Transition/

s6.4.4/Figure 9/Figure 10: Events EVE_DHCP_RENEW and EVE_DHCP_REBIND are 
missing from the table, list and diagram.  They should be marked as 
cycling in the BOUND state.  Putting them in here is desirable so that 
it is consistent with the table/diagrams in s7.9 etc.

s7.1, para 1: s/two case when this does not work/two cases when this 
does not work/

s7.1, bullet #1: s/everyone/every one/;
                            s/passing by the SAVI device/passing through 
the SAVI device/

s7.1, bullet #2: s/turns broken/becomes broken/;
                            s/as planned/some planned change/

s7.1, para after bullets:
OLD:
    Data Snooping Process prevents permanently blocking legitimate
    traffic in case of these two exceptions.
NEW:
    The Data Snooping Process can avoid the permanent blocking of legitimate
    traffic in case one of these two exceptions occurs.

s7.1, next to last para: s/a conditional SHOULD/OPTIONAL/;
         s/without the above exceptions/where the exceptions cannot occur/

s7.1, last para:  Mention that the probability of unmatched packets 
triggering the Data Snooping Process should be a configurable parameter 
of implementations.  Presumably the default should be zero so it is 
normally turned off.

s7.2, last para: s/about this process is discussed is/concerning this 
process are discussed in/

s7.3: The way in which the Data Snooping process integrates with the 
DHCP Snooping Process is not explained until the very end of s7 (in 
s7.8) and even then very tersely.  I suggest adding the following to s7.3:
NEW:
     The Data Snooping Process provides an alternative path for binding 
entries
     to reach the BOUND state in the exceptional cases explained in 
Section 7.1
     when there are no DHCP messages that can be snooped by the SAVI device.

     In some of the exceptional cases (especially the dynamic topology 
case), by
     the time the binding has reached the BOUND state the DHCP messages may
     be passing through the SAVI device.  In this case the events driven 
by DHCP
     messages that are expected in the BOUND state in the DHCP Snooping 
Process
     may occur and the binding can be handled by the DHCP Snooping Process
     state machine.

     In any event, the lease expiry timeout event will occur even if no 
others do.
     This will cause the binding to be deleted and the state to 
logically return to
     NO_BIND state.  Either the DHCP or the Data Snooping Process will be
     reinvoked if the lease is still place.  If DHCP messages are still 
not passing
     through the SAVI device, there will be a brief disconnection during 
which
     data packets passing through the SAVI device will be dropped. The
     probabilistic initiation of the Data Snooping Process can then take 
over again
     and return the binding state to BOUND in due course.

s7.4, para 1: s/In addition to EVE_DATA_LEASEQUERY and 
EVE_DHCP_REBIND,/In addition to EVE_DHCP_RENEW and EVE_DHCP_REBIND,/

s7.4, para 1:  To make the BOUND state consistent with the DHCP Snooping 
Process case, the events EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, 
EVE_DHCP_REPLY, and EVE_DHCP_LEASEQUERY should also be processed in the 
BOUND state.  The actions in the BOUND state can be explained by a 
reference to s6.4.3 rather than having to repeat them in s7.

s7.5-s7.7:  The textual description of the actions is not an accurate 
representation of the evolution of the state machine, primarily because 
the sending of the second neighbour detection and second lease query 
messages is shown in the wrong state.  This means that the detection 
messages would not be received in the expected states.  The way to fix 
this is to define three "functions" (as is normally done for state 
machines).    The functions would subsume the text about sending ARP/DAD 
messages in s7.5.1, the text about sending lease queries in s7.6.1 and 
sending ARP requests in s7.7.1. A third intermediate state is needed to 
handle the three response messages or timeouts from the three remote 
messages.  As it stands, the actions after an UNMATCH event (s7.5.1) 
involve transmitting messages and waiting for responses or timeouts.  
The text is unclear exactly when the transition to the DETECTION state 
occurs, and the EVE_ENTRY_EXPIRE actions in DETECTION (s7.6.1) do not 
handle the retransmission of the ARP/DAD requests (see s7.5.1) but set 
about sending lease queries.  The BST needs an expire counter entry to 
simplify the number of states.  The sequence (for v4) needs to go 
something like:
[NO_BIND] UNMATCH recd and decided to act
[NO_BIND] Set expiry count -> 0; Send ARP; Set timeout to 
DETECTION_TIMEOUT; Transition to [DETECTION]
[DETECTION] CONFLICT recd => abort and discard binding; Transition to 
[NO_BIND]
[DETECTION] EXPIRY: Increment expiry count;
                          if count == 1: Send ARP; Set timeout to 
DETECTION_TIMEOUT; Remain in state [DETECTION];
                          else if count ==2: Send lease query; Set 
timeout to LEASEQUERY_DELAY; set count to 0; Transition to state [RECOVERY]
... and similar in state RECOVERY.. an extra state is needed to handle 
the ARP etc after successful lease query.

s7.5.1:
>     This local conflict process SHOULD be performed.  If it is not
>     performed, the state of the entry is set to RECOVERY, the lifetime is
>     set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified
>     in the following section will be performed directly.
Under what circumstances would the local conflict process not be performed?
If the sequence noted above is used, the lease query process can be 
triggered by  setting the expiry count to 0 and sending the lease query 
request before transitioning to state RECOVERY.

s7.6.1, item (1): s/A list of authorized DHCP servers are kept/A list of 
authorized DHCP servers is kept/

s7.8/s7.9/Figure 13/Figure 14: s/Transit/Transition/ (4 places)

s8: The filtering of DHCP messages needs to apply to the various lease 
query and lease query response messages.  The relevant messages need to 
be either added to the appropriate one from Client-Server and 
server-to-Client category, or a new category created and mentioned with 
the existing categories (see comment on s3 above).

   s9.1, para 2: s/attribute can be found/attributes can be found/

s9.2, para 1: s/discard legitimate/to discard legitimate/; 
s/Purely/Simply/; s/is of/is a/;
                       s/considerable/may cause considerable/
s9.2, last para:
OLD:
    Immediately after reboot, the SAVI device SHOULD restore binding
    states from the non-volatile storage.  The system time of save
    process MUST be stored.  After rebooting, the SAVI device MUST check
    whether each entry has been obsolete by comparing the saved lifetime
    and the difference between the current time and time when the binding
    entry is established.
NEW
    Immediately after reboot, the SAVI device SHOULD restore the binding
    states from the non-volatile storage.   Using the time when each 
binding
    entry was saved, the SAVI device should check whether the entry has
    become obsolete by comparing the saved lifetime and the difference
    between the current time and time when the binding entry was 
established.
    Obsolete entries which would have expired before the reboot MUST be 
removed.

s11.2:  This section adds additional states/events/actions into the 
state machine.  The link-down event and its consequences aren't really a 
security consideration.

s11.3: I am unclear how the processes described could lead to multiple 
binding anchors being established on the same SAVI device. Could you 
quote an example please?  I am unsure how a client with multiple 
attachments could be using the same address on each of them.

s11:  As discussed on various previous occasions, lease query operations 
are considered security sensitive [RFC5007] [RFC4388]. It is recommended 
that an IPsec channel is opened to carry out lease query enquiries.   
However, since the number of SAVI devices and DHCP servers/relays in a 
typical network is relatively small and they will all be under the 
control of a single administrative authority, keying material can be 
prepositioned out of band and used as necessary by SAVI devices that 
know the addresses of the DHCP entities.  This needs to be described in 
an extra section in s11. It may also be the case that in some 
circumstances, the SAVI protection itself could be considered sufficient 
to obviate the need for using IPsec channels - however, that needs to be 
discussed and I suggest that the authors consult with a security expert 
(i.e., not me) to decide what is appropriate.