Telechat Review of draft-ietf-savi-dhcp-29

Request Review of draft-ietf-savi-dhcp
Requested rev. no specific revision (document currently at 34)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-09-11
Requested 2012-08-16
Authors Jun Bi, Jianping Wu, Guang Yao, Fred Baker
Draft last updated 2013-02-27
Completed reviews Genart Last Call review of -?? by Elwyn Davies
Genart Last Call review of -?? by Elwyn Davies
Genart Telechat review of -29 by Elwyn Davies (diff)
Genart Telechat review of -29 by Elwyn Davies (diff)
Genart Telechat review of -32 by Elwyn Davies (diff)
Assignment Reviewer Elwyn Davies
State Completed
Review review-ietf-savi-dhcp-29-genart-telechat-davies-2013-02-27
Reviewed rev. 29 (document currently at 34)
Review result Not Ready
Review completed: 2013-02-27


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

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

Document: draft-ietf-savi-dhcp-29.txt
Reviewer: Elwyn Davies
Review Date: 19 August 2014
IETF LC End Date: -
IESG Telechat date: 4 September 2014


This draft still has several open issues some of which could be 

classified as serious issues.  There are also several areas, especially 

in the specification of the state machine (or is it machines) where the 

document does not lend itself to the making of reliably interoperable 


Major issues:
General: I noted in my two previous reviews of this document back in
2012 that the document was (desperately) in need of a general editorial
pass from an English mother tongue editor.  This has only partially been
carried out and the document still contains many grammatical errors.
Regrettably, the effect of this unclear and erroneous language makes
some areas of the document technically ambiguous and other areas

unnecessarily difficult to understand for readers. Additionally the 

structuring of certain parts (especially specification of the the state 

machine(s)) really needs major rework to make it readily implementable.

s4.3.5/s11.2:  Of the six possible properties that could be used to set 

up binding anchors, only two are discussed in this section.  What about 

the other four?  Are they usable with SAVI-DHCP or not?   I am 

particularly concerned about how SAVI-DHCP interacts with wi-fi networks 

which seems not to be considered at all - rather the pictures and 

descriptions all seem to imply wired networks with a one-to-one 

relationship between connected devices and SAVI device ports.  The 

problem of 'leaving clients' (not a very felicitous phrase) with 

networks other than one-to-one direct attachments is left open.  The 

wording at the end of s11.2, seems to indicate that SAVI-DHCP may not be 

useful other than for with one-to-one direct attachment.

s3/s4 (and elsewhere): The definitions in s3 and the descriptions of the
need to distinguish between upstream and downstream links would appear
to rule out the use of SAVI as currently specified in situations where
transit traffic and destination traffic share the same link.  Presumably

this rules out quite a few wi-fi networks, for example IPv6 networks 

with multiple subnets per link and possibly situations where there are 

multiple routers in series.

s7.5.1.2:  The local conflict resolution process will not work on wi-fi 

networks AFAICS because there is no way to stop the detection messages 

being sent to the node that originated the unmatched message.  Is this a 

problem or not?  Some discussion is desirable in any case.

Minor issues:

Introductory boilerplate: Since the earliest date on versions of this
draft is 2009, it is unclear why the pre-2008 material disclaimer is
relevant.  Could this be explained or removed if not necessary, please.

s1: The reference to RFC 2827 (aka BCP38) might better refer to the more
extensive RFC 3704 (BCP 84) - and, in any case, use the BCP reference
rather than the RFC to cover any future update.

s4.2.5/s4.2.6:  It is not clear to me why there needs to be a separate 

VALIDATING attribute.  It is required to be set with DHCP-Snooping and 

Data-Snooping and is only optional with DHCP-Trust.  However, it is 

unclear under what circumstances there could be any binding entries on 

an attachment that is only configured with DHCP-Trust since binding 

entries can only be created as a result of having one of the *-Snooping 

attributes set.  Consequently it seems that all that is needed is for 

the two *-Snooping attributes imply the effect of the VALIDATING attribute.

s6.4.2.2, item 2.1: Does there need to be any distinction between 

permanent and temporary addresses (RFC 3315 ss22.4 and 22.5)?  In 

particular, RFC 3041 indicates that temporary addresses may remain in 

use as source/destination addresses after their notional lifetimes have 

expired if a connection for which they were used remains open after the 

expiry.  Also the timeout parameters on permanent and temporary 

addresses are different in DHCPv6 (RFC3315 again).

s6.4.2.2/s11:  RFC 5007 recommends that LEASEQUERY/LEASEQUERY_REPLY 

messages should be protected by IPsec as described in s21 of RFC 3315 

when used by devices that are similar in operation to SAVI-DEVICEs (RFC 

5007 s5).  It is quite likely that DHCP servers would not answer 

LEASEQUERY messages from addresses that are not IP addresses leased by 

the server unless the messages were received over a trusted IPsec 

connection.  This issue is not discussed in the draft.  The suggestion 

in RFC 5007 indicates that pre-shared keys would be feasible because of 

the small number and relatively stable association of DHCP server(s) and 

SAVI-DHCP devies. This also means that sending LEASEQUERY to the 

ALL_DHCP_SERVERS multicast address is quite likely not to elicit responses.

s7: The previous comment applies to the use of DHCPLEASEQUERY and 

LEASEQUERY in the Data-Snooping state machine also.

s6.4.2: Forwarding of DHCP messages: There is some inconsistent logic 

here - some messages that are snooped on are specifically noted as 'MUST 

be forwarded' whereas nothing is said about forwarding messages that are 

not 'specially processed'.  The SAVI-DEVICE is *snooping* on all these 

messages; thus all of the messages apart from LEASEQUERY_REPLYs 

resulting from LEASEQUERY requests generated by the SAVI-DEVICE MUST be 

forwarded to their intended destination.  This could be covered by a 

general statement about all DHCP messages passing through the 

SAVI-DEVICE, eliminating all the confusing statements about certain 

messages having to be forwarded.

s7: Specifying the Data-Snooping state machine as a modification of the 

DHCP-Snooping state machine is confusing.  If they really can be 

combined it would be much nicer to specify the machine in one place and 

have done with it.  If not they should be specified separately.  It is 

currently difficult to know if the combined machine will work correctly 

if it gets driven by a combination of DHCP and data snooping events.  In 

particular, if the s7 machine really is a superset of the s6 machine the 


10) should trigger a transition back to the NO_BIND state but they 

aren't mentioned in Figure 14.

s8, para 2:

DHCP and NDP (Neighbor Discovery Protocol) [RFC4861]
   messages that may cause state transit are classified as control

So does this mean that DHCP and NDP messages that do not affect the 

state machines are treated as data packets? This may or may not be 

inconsistent with the statements in s8.2.


The SAVI device MAY record any violation.

Is any mechanism or suggestion needed to avoid log overload?

Also the term 'violation' is not explicitly defined.  Presumably it 

means any packet that is dropped as a result of failing validation.

Nits/editorial comments:

s1: definition of "binding anchor":  Although binding anchors are
discussed in detail in Section 3 (which is pointed to) the fundamental
nature of "binding anchor" in this work means that an outline definition
is desirable in s1.

s1, para 1:
Strictly, the mechanism does not affect the validity or otherwise of the
source IP addresses used, but provides a validation mechanism that
checks that validity.  I suggest:
   Compared with [RFC2827], which provides
   prefix granularity source IP address validity, this mechanism can
   benefit the network with finer-grained validity and traceability of
   source IP addresses.
   Compared with [RFC2827], which provides validation of
   source IP addresses at the granularity of subnet prefixes, this
   mechanism can benefit the network with finer-grained validation and
   traceability of the origin of forged source IP addresses.


Binding anchor: A "binding anchor" is defined to be a link layer
property of network attachment in [RFC7039].  A list of proper
binding anchors can be found in Section 3.2 of [RFC7039].

Three issues:
- This definition is subtly different from the form in RFC 7039 (s2,
bullet 2).  There a binding anchor is not a separate link layer property
but an *indirection* to an existing link layer property with the
appropriate value for a host's network attachment bound to the
legitimate IP address in such a way that a SAVI mechanism can verify
legitimate usage of the IP address in the link layer.
- I would suggest that 'proper' is not the appropriate word.  'Possible'
seems more in keeping with s3.2 of RFC 7039.
- RFC 7039 uses "link-layer" rather than "link layer".  This draft has
both (c.f. s5, bullet 1).  Please be consistent - matching RFC 7039 is

probably best so select "link-layer".  There are also three instances of 

layer-2 in s7.1; these should also be link-layer..

Suggested rewording:
   Binding Anchor: A selected link-layer property of a host's network
   attachment that can be verifiably bound to the legitimate IP address
   associated with that attachment point as described in Section 2 of
   [RFC7039].  Section 3.2 of [RFC7039] has a list of possible
   properties that might be used as binding anchors.


Attribute: A configurable property of each network attachment which
indicates the actions to be performed on packets received from the
network attachment.

This is confusing because network attachment is not associated with a
device here.  Presumably it is the SAVI device that will be doing the
actions whereas the binding anchor has talked about the host's network

s3, Upstream links: As written this appears to imply that these links
are between non-SAVI devices.  I take it that what is really meant is
links between a SAVI device and a non-SAVI device outside the monitored
network (i.e., not a monitored host or an access device as mentioned in
the Indirect Attachment definition).  The same implication is, to a
lesser extent, true of the Downstream links definition.

s3, CUT VERTEX:  Why is this term all in upper case? The definition uses
lower case.

s4, Figure 1: It would avoid confusing the association of the 'upstream
link' label if it was placed outside the 'Protection Perimeter' outline.
My initial reading was that 'upstream link' labelled the perimeter box.
 It might also be less confusing if the horizontal lines of the
perimeter box used a less dense line (e.g., . . . . . instead of
.........) as the difference between the perimeter and the edges of
devices is not very clear at a distance.


Networks are not isolated and traffic from other networks, i.e.,
transit traffic specified in [RFC6620], may get into the network
with SAVI-DHCP deployed through the upstream links.  Since SAVI
solutions are limited to check traffic generated from local link,
SAVI-DHCP is not to set up bindings for addresses assigned in other

Presumably in a network that deals with end hosts as shown in Figure 1
there is likely to be quite a lot of traffic coming from other networks
that isn't transit traffic.  Singling out transit traffic is confusing
particularly in the Figure 1 example since the complete SAVI protection
perimeter and the devices not on the upstream link are a 'leaf' network
with no outlets to other networks.  So I guess it should be e.g. rather
than i.e., and it would be good to actually mention the traffic destined
for the validated end hosts!

s4.2, para 2:

Before configuration, an attachment is with no attribute.  An
attachment MAY be configured to have one or more compatible
attributes (refer to Section 4.2.6).

s/is with no attribute/starts out with an empty attribute set/

It would be clearer to use 'empty attribute set' instead of 'no 

attribute' throughout.

s/MAY/can/ - this is something the administrator controls and not an
implementation constraint for the mechanism.

s4.2, para 2:

The attributes of each attachment MUST be configured before the
SAVI-DHCP function is enabled.

Again this is an administrator control and not an RFC 2119 requirement,

but as written it appears to make it impossible to reconfigure a 

SAVI-DEVICE without disabling and reenabling SAVI-DHCP.  Not very 

operationally friendly!

s4.2, para 3: s/SUGGESTED/RECOMMENDED/ - SUGGESTED is not in the RFC 

2119 set. (also applies to s6.4.2.2 item 2.1 - but SUGGESTED is spelt 


s4.2.1: It might be desirable to rename the 'Trust' attribute as 

'Full-Trust' to make it clear what it means and avoid issues with 

misremembered configurations.

s4.2.2, last para:

   The implementation for DHCPv6 can refer to
   [I-D.ietf-opsec-dhcpv6-shield] for more details.

'implementation'??? This does not refer to an implementation of the 

SAVI-DHCP function.  I presume the draft is suggesting that SAVI-DHCP 

might be combined with a deployment of the DHCPv6 Shield technology on 

relevant links.

s4.3.5, para 1: s/By default,t his/By default, this/

s6.4.1.2: Given the distance between s2 and this section, it would be 

useful to expand IA on its first use in this section.

ss6.4.2.2/  It would be much clearer if the new state for the 

'Following Actions' in each case was given an explicit "New State" line 

and also separating the different events into separate subsections (OK I 

know it is then 5 levels deep, but that is the way of state machines!)