DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers
draft-ietf-opsec-dhcpv6-shield-08

[Ballot comment]
I'm not going to block on this, but it seems weird to me that this would be a BCP. (And I see I am not the first to ask about that.)

[Ballot comment]
I see that the normative recommendations about logging have been removed, so I am clearing my DISCUSS. However, I still think the document would be better if it explained the difference between a security fault and a security alert. I don't understand what the difference is supposed to be.

Also, it seems the changes I had suggested in my COMMENT originally were not adopted -- not sure if that was on purpose or an oversight.

= Section 1 =
s/meant to DHCPv6 clients/intended for DHCPv6 clients/

s/a specific ports/specific ports/

s/DCHPv6-Shield/DHCPv6-Shield/

s/only mitigates only/only mitigates/

= Section 5 =
I support all of the changes to Section 5 suggested by Pete.

I don't think the spec should recommend logging packet drop events unless it explains what is meant to be done with the logs.

[Ballot discuss]
When I began with this DISCUSS, my understanding was that in order to implement DHCPv6 Shield and be sure of stopping all DHCP packets, it would, as the document says, be necessary to filter packets with unknown IPv6 headers.  This would likely mean that the layer 2 switching fabric of a network supporting DHCPv6 shield would be unable to carry any IP packets containing not only unknown IP extension headers, but also packets containing unknown (to the switching fabric) protocol headers.  Consequently I suggested a fairly elaborate way to mitigate the risk without requiring that all such packets be filtered.

However, after discussing this at length with Fernando, I realized that it was actually not at all necessary to filter unknown IPv6 headers.  The reason for this is that we can safely assume that any IP extension header that appears in a packet conforms to RFC 6564.  This means that switches implementing DHCPv6 shield can at least in principle skip over unknown IP extension headers.  If an unknown protocol header is seen, this will look to the switch like a malformed IP extension header, but this is harmless in the context of DHCPv6 shield because any such packet is by definition _not_ a DHCPv6 packet.  I believe that a switching fabric should not default to dropping packets it doesn't recognize, because this pretty much guarantees that new protocols can't be deployed even in site-specific situations.

Therefore, I believe that this document should not only not require filtering unknown IP extension headers, but should not even mention filtering them.  It may be that some implementations may need to filter them for other reasons, but this is already allowed by RFC 7045, and therefore needn't be mentioned here.quot;Bad TRIP Identifier."  A TRIP
  identifier is 4-octets in length and can take any value.  An LS
  considers the TRIP Identifier invalid if it already has an open
  connection with another peer LS that has the same ITAD and TRIP
  Identifier.

  Any two LSs within the same ITAD MUST NOT have equal TRIP Identifier
  values.  This restriction does not apply to LSs in different ITADs
  since the purpose is to uniquely identify an LS using its TRIP
  Identifier and its ITAD number.

  If one of the Optional Parameters in the OPEN message is not
  recognized, then the Error Subcode MUST be set to "Unsupported
  Optional Parameters."

  If the Optional Parameters of the OPEN message include Capability
  Information with an unsupported capability (unsupported in either
  capability type or value), then the Error Subcode MUST be set to
  "Unsupported Capability," and the entirety of the unsupported
  capabilities MUST be listed in the Data field of the NOTIFICATION
  message.

  If the Optional Parameters of the OPEN message include Capability
  Information which does not match the receiving LS's capabilities,
  then the Error Subcode MUST be set to "Capability Mismatch," and the
  entirety of the mismatched capabilities MUST be listed in the Data
  field of the NOTIFICATION message.

6.3. UPDATE Message Error Detection and Handling

  All errors detected while processing the UPDATE message are indicated
  by sending the NOTIFICATION message with the Error Code "UPDATE
  Message Error."  The Error Subcode elaborates on the specific nature
  of the error.  The error checks in this section MUST be performed by
  each LS upon receipt of every UPDATE message.  These error checks
  MUST occur before flooding procedures are invoked with internal
  peers.

Rosenberg, et. al.          Standards Track                    [Page 46]
RFC 3219            Telephony Routing over IP (TRIP)        January 2002

  If any recognized attribute has Attribute Flags that conflict with
  the Attribute Type Code, then the Error Subcode MUST be set to
  "Attribute Flags Error."  The Data field contains the erroneous
  attribute (type, length and value).

  If any recognized attribute has an Attribute Length that conflicts
  with the expected length (based on the attribute type code), then the
  Error Subcode MUST be set to "Attribute Length Error."  The Data
  field contains the erroneous attribute (type, length and value).

  If any of the mandatory (i.e., conditional mandatory attribute and
  the conditions for including it in the UPDATE message are fulfilled)
  well-known attributes are not present, then the Error Subcode MUST be
  set to "Missing Well-known Mandatory Attribute."  The Data field
  contains the Attribute Type Code of the missing well-known
  conditional mandatory attributes.

  If any of the well-known attributes are not recognized, then the
  Error Subcode MUST be set to "Unrecognized Well-known Attribute."
  The Data field contains the unrecognized attribute (type, length and
  value).

  If any attribute has a syntactically incorrect value, or an undefined
  value, then the Error Subcode is set to "Invalid Attribute."  The
  Data field contains the incorrect attribute (type, length and value).
  Such a NOTIFICATION message is sent, for example, when a
  NextHopServer attribute is received with an invalid address.

  The information carried by the AdvertisementPath attribute is checked
  for ITAD loops.  ITAD loop detection is done by scanning the full
  AdvertisementPath, and checking that the ITAD number of the local
  ITAD does not appear in the AdvertisementPath.  If the local ITAD
  number appears in the AdvertisementPath, then the route MAY be stored
  in the Adj-TRIB-In.  However unless the LS is configured to accept
  routes with its own ITAD in the advertisement path, the route MUST
  not be passed to the TRIP Decision Process.  The operation of an LS
  that is configured to accept routes with its own ITAD number in the
  advertisement path are outside the scope of this document.

  If the UPDATE message was received from an internal peer and either
  the WithdrawnRoutes, ReachableRoutes, or ITAD Topology attribute does
  not have the Link-State Encapsulation flag set, then the Error
  Subcode is set to "Invalid Attribute" and the data field contains the
  attribute.  Likewise, the attribute is invalid if received from an
  external peer and the Link-State Flag is set.

  If any attribute appears more than once in the UPDATE message, then
  the Error Subcode is set to "Malformed Attribute List."

Rosenberg, et. al.          Standards Track                    [Page 47]
RFC 3219            Telephony Routing over IP (TRIP)        January 2002

6.4. NOTIFICATION Message Error Detection and Handling

  If a peer sends a NOTIFICATION message, and there is an error in that
  message, there is unfortunately no means of reporting this error via
  a subsequent NOTIFICATION message.  Any such error, such as an
  unrecognized Error Code or Error Subcode, should be noticed, logged
  locally, and brought to the attention of the administration of the
  peer.  The means to do this, however, are outside the scope of this
  document.

6.5. Hold Timer Expired Error Handling

  If a system does not receive successive messages within the period
  specified by the negotiated Hold Time, then a NOTIFICATION message
  with a "Hold Timer Expired" Error Code MUST be sent and the TRIP
  connection MUST be closed.

6.6. Finite State Machine Error Handling

  An error detected by the TRIP Finite State Machine (e.g., receipt of
  an unexpected event) MUST result in sending a NOTIFICATION message
  with the Error Code "Finite State Machine Error" and the TRIP
  connection MUST be closed.

6.7. Cease

  In the absence of any fatal errors (that are indicated in this
  section), a TRIP peer MAY choose at any given time to close its TRIP
  connection by sending the NOTIFICATION message with the Error Code
  "Cease."  However, the Cease NOTIFICATION message MUST NOT be used
  when a fatal error indicated by this section exists.

6.8. Connection Collision Detection

  If a pair of LSs try simultaneously to establish a transport
  connection to each other, then two parallel connections between this
  pair of speakers might well be formed.  We refer to this situation as
  connection collision.  Clearly, one of these connections must be
  closed.

  Based on the value of the TRIP Identifier, a convention is
  established for detecting which TRIP connection is to be preserved
  when a collision occurs.  The convention is to compare the TRIP
  Identifiers of the peers involved in the collision and to retain only
  the connection initiated by the LS with the higher-valued TRIP
  Identifier.

Rosenberg, et. al.          Standards Track                    [Page 48]
RFC 3219            Telephony Routing over IP (TRIP)        January 2002

  Upon receipt of an OPEN message, the local LS MUST examine all of its
  connections that are in the OpenConfirm state.  An LS MAY also
  examine connections in an OpenSent state if it knows the TRIP
  Identifier of the peer by means outside of the protocol.  If among
  these connections there is a connection to a remote LS, whose TRIP
  Identifier equals the one in the OPEN message, then the local LS MUST
  perform the following collision resolution procedure:

  The TRIP Identifier and ITAD of the local LS is compared to the TRIP
  Identifier and ITAD of the remote LS (as specified in the OPEN
  message).  TRIP Identifiers are treated as 4-octet unsigned integers
  for comparison.

  If the value of the local TRIP Identifier is less than the remote
  one, or if the two TRIP Identifiers are equal and the value of the
  ITAD of the local LS is less than value of the ITAD of the remote LS,
  then the local LS MUST close the TRIP connection that already exists
  (the one that is already in the OpenConfirm state), and accept the
  TRIP connection initiated by the remote LS:

      1. Otherwise, the local LS closes the newly created TRIP
        connection and continues to use the existing one (the one that
        is already in the OpenConfirm state).
      2. If a connection collision occurs with an existing TRIP
        connection that is in the Established state, then the LS MUST
        unconditionally close off the newly created connection.  Note
        that a connection collision cannot be detected with connections
        in Idle, Connect, or Active states.
      3. To close the TRIP connection (that results from the collision
        resolution procedure), an LS MUST send a NOTIFICATION message
        with the Error Code "Cease" and the TRIP connection MUST be
        closed.

7. TRIP Version Negotiation

  Peer LSs may negotiate the version of the protocol by making multiple
  attempts to open a TRIP connection, starting with the highest version
  number each supports.  If an open attempt fails with an Error Code
  "OPEN Message Error" and an Error Subcode "Unsupported Version
  Number," then the LS has available the version number it tried, the
  version number its peer tried, the version number passed by its peer
  in the NOTIFICATION message, and the version numbers that it
  supports.  If the two peers support one or more common versions, then
  this will allow them to rapidly determine the highest common version.
  In order to support TRIP version negotiation, future versions of TRIP
  must retain the format of the OPEN and NOTIFICATION messages.

Rosenberg, et. al.          Standards Track                    [Page 49]
RFC 3219            Telephony Routing over IP (TRIP)        January 2002

8. TRIP Capability Negotiation

  An LS MAY include the Capabilities Option in its OPEN message to a
  peer to indicate the capabilities supported by the LS.  An LS
  receiving an OPEN message MUST NOT use any capabilities that were not
  included in the OPEN message of the peer when communicating with that
  peer.

9. TRIP Finite State Machine

  This section specifies TRIP operation in terms of a Finite State
  Machine (FSM).  Following is a brief summary and overview of TRIP
  operations by state as determined by this FSM.  A condensed version
  of the TRIP FSM is found in Appendix 1.  There is one TRIP FSM per
  peer and these FSMs operate independently.

  Idle state:
  Initially TRIP is in the Idle state for each peer.  In this state,
  TRIP refuses all incoming connections.  No resources are allocated to
  the peer.  In response to the Start event (initiated by either the
  system or the operator), the local system initializes all TRIP
  resources, starts the ConnectRetry timer, initiates a transport
  connection to the peer, starts listening for a connection that may be
  initiated by the remote TRIP peer, and changes its state to Connect.
  The exact value of the ConnectRetry timer is a local matter, but
  should be sufficiently large to allow TCP initialization.

  If an LS detects an error, it closes the transport connection and
  changes its state to Idle.  Transitioning from the Idle state
  requires generation of the Start event.  If such an event is
  generated automatically, then persistent TRIP errors may result in
  persistent flapping of the LS.  To avoid such a condition, Start
  events MUST NOT be generated immediately for a peer that was
  previously transitioned to Idle due to an error.  For a peer that was
  previously transitioned to Idle due to an error, the time between
  consecutive Start events, if such events are generated automatically,
  MUST exponentially increase.  The value of the initial timer SHOULD
  be 60 seconds, and the time SHOULD be at least doubled for each
  consecutive retry up to some maximum value.

  Any other event received in the Idle state is ignored.

  Connect State:
  In this state, an LS is waiting for a transport protocol connection
  to be completed to the peer, and is listening for inbound transport
  connections from the peer.

Rosenberg, et. al.          Standards Track                    [Page 50]
RFC 3219            Telephony Routing over IP (TRIP)        January 2002

 

[Ballot comment]
This is the original text of this DISCUSS:

This text makes sense, but I think it needs to be changed somewhat:

  3.  When parsing the IPv6 header chain, if the packet is identified
      to be a DHCPv6 packet meant for a DHCPv6 client or the packet
      contains an unrecognized Next Header value, DHCPv6-Shield MUST
      drop the packet, and SHOULD log the packet drop event in an
      implementation-specific manner as a security alert.
      DHCPv6-Shield MUST provide a configuration knob that controls
      whether packets with unrecognized Next Header values are dropped;
      this configuration knob MUST default to "drop".

          RATIONALE: An unrecognized Next Header value could possibly
          identify an IPv6 Extension Header, and thus be leveraged to
          conceal a DHCPv6-server packet (since there is no way for
          DHCPv6-Shield to parse past unrecognized Next Header values
          [I-D.gont-6man-rfc6564bis]).  [RFC7045] requires that nodes be
          configurable with respect to whether packets with unrecognized
          headers are forwarded, and allows the default behavior to be
          that such packets be dropped.

I think it's worth considering whether the default setting for this configuration knob should be "drop" or "pass."  The problem with defaulting to "drop" is that it means that extension headers the DHCPv6 Shield device does not understand fail to pass, which could cause operational problems.  The problem with not defaulting to "drop" you have already explained.  I do not think that the threat of DHCPv6 spoofing is sufficient to justify defaulting to drop.  Yes, DHCPv6 spoofing can cause operational issues.  So can filtering "unknown" headers.

The frustrating thing about this document is that it actually solves the problem the wrong way.  What this document should recommend is filtering of DHCPv6 packets from _clients_.  If a rogue DHCP server can't see client multicasts because DHCPv6 shield is blocking them, then it can't know to attack DHCPv6 clients.  This substantially limits the rogue's ability to attack DHCPv6 clients on the local subnet.  If you combine that with server packet filtering but do not block unknown headers, I think you have achieved a good tradeoff between the problems caused by whatever spoofing might get to a client using an unknown header and the problems caused by blocking non-DHCP packets that use that unknown header for some legitimate purpose.

So, realizing that this would be a major change, the way I would LIKE you to address this discuss is to add DHCPv6 client packet filtering.  You could also address it by changing the default for the unknown header filter, but I would understand if you felt that this was inadequate.  Or you could argue persuasively that I'm wrong, which has been known to happen. :)

[Ballot discuss]
This text makes sense, but I think it needs to be changed somewhat:

  3.  When parsing the IPv6 header chain, if the packet is identified
      to be a DHCPv6 packet meant for a DHCPv6 client or the packet
      contains an unrecognized Next Header value, DHCPv6-Shield MUST
      drop the packet, and SHOULD log the packet drop event in an
      implementation-specific manner as a security alert.
      DHCPv6-Shield MUST provide a configuration knob that controls
      whether packets with unrecognized Next Header values are dropped;
      this configuration knob MUST default to "drop".

          RATIONALE: An unrecognized Next Header value could possibly
          identify an IPv6 Extension Header, and thus be leveraged to
          conceal a DHCPv6-server packet (since there is no way for
          DHCPv6-Shield to parse past unrecognized Next Header values
          [I-D.gont-6man-rfc6564bis]).  [RFC7045] requires that nodes be
          configurable with respect to whether packets with unrecognized
          headers are forwarded, and allows the default behavior to be
          that such packets be dropped.

I think it's worth considering whether the default setting for this configuration knob should be "drop" or "pass."  The problem with defaulting to "drop" is that it means that extension headers the DHCPv6 Shield device does not understand fail to pass, which could cause operational problems.  The problem with not defaulting to "drop" you have already explained.  I do not think that the threat of DHCPv6 spoofing is sufficient to justify defaulting to drop.  Yes, DHCPv6 spoofing can cause operational issues.  So can filtering "unknown" headers.

The frustrating thing about this document is that it actually solves the problem the wrong way.  What this document should recommend is filtering of DHCPv6 packets from _clients_.  If a rogue DHCP server can't see client multicasts because DHCPv6 shield is blocking them, then it can't know to attack DHCPv6 clients.  This substantially limits the rogue's ability to attack DHCPv6 clients on the local subnet.  If you combine that with server packet filtering but do not block unknown headers, I think you have achieved a good tradeoff between the problems caused by whatever spoofing might get to a client using an unknown header and the problems caused by blocking non-DHCP packets that use that unknown header for some legitimate purpose.

So, realizing that this would be a major change, the way I would LIKE you to address this discuss is to add DHCPv6 client packet filtering.  You could also address it by changing the default for the unknown header filter, but I would understand if you felt that this was inadequate.  Or you could argue persuasively that I'm wrong, which has been known to happen. :)

[Ballot comment]

There is one thing here I can't figure out, maybe you can
enlighten me though...

section 5, bullet 3: this seems like another "don't make it
easier to use IPv6 rule" and as a default, which I can't
figure.  Why do you even need to block "an unrecognized Next
Header value" to protect against a spoofed DHCPv6 response
message?

- intro: s/meant to/sent to/ ?

[Ballot discuss]
= Section 5 =

I think the point that Pete makes about sub-bullet 3 is valid, and that it's possible for an implementer to do the wrong thing because of the confused way in which sub-bullet 3 is written. I think this can be resolved by adopting the changes that Pete suggests.

If you choose to not adopt all of Pete's changes in Section 5 and retain the normative recommendations about logging, I'd like to discuss what the difference is between a security fault and a security alert. It's hard for me to see how the spec can normatively recommend implementation-specific behavior and then use two different terms for what that behavior is supposed to entail without explaining the difference between them. (And even if you remove the normative logging recommendations, it would still help to explain what the difference is, but that would no longer be DISCUSS-worthy I think.)

[Ballot comment]
= Section 1 =
s/meant to DHCPv6 clients/intended for DHCPv6 clients/

s/a specific ports/specific ports/

s/DCHPv6-Shield/DHCPv6-Shield/

s/only mitigates only/only mitigates/

= Section 5 =
I support all of the changes to Section 5 suggested by Pete.

I don't think the spec should recommend logging packet drop events unless it explains what is meant to be done with the logs.

[Ballot comment]
I'd like to understand why this is a BC and if that's the right designation.  Hannes brought this up in his SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05273.html

[Ballot comment]
Abstract:

  This document specifies
  a Best Current Practice for the implementation of DHCPv6 Shield.

No, this does not specify a Best Current Practice *for* implementing DHCPv6-Shield; it's a Best Current Practice *for* the Internet (or some portion thereof). A "Best Current Practice" is not something that you specify. This document *does* specify "a set of operational practices or guidelines for implementation of DHCPv6 Shield." Say that instead.

Section 4: s/MUST be/is

Section 5:

OLD
  The following filtering rules MUST be enforced as part of a
NEW
  The following are the filtering rules that are enforced as part of

Sub bullet 2:

  s/SHOULD log the packet/ought to log the packet

(That's not an implementation requirement, just something good to do.)

Sub bullet 2:

  s/MUST contain the/must contain the

(That's just  re-describing something in another document, not a new requirement.)

Sub bullet 3, first paragraph: The first sentence contradicts the second sentence as it's written with regard to unrecognized Next Header values. I suggest splitting this up:

  3.  DHCPv6-Shield MUST provide a configuration knob that controls
      whether packets with unrecognized Next Header values are dropped;
      this configuration knob MUST default to "drop". When parsing the
      IPv6 header chain, if the packet contains an unrecognized Next
      Header value and the configuration knob is configured to "drop",
      DHCPv6-Shield MUST drop the packet, and ought to log the packet
      drop event in an implementation-specific manner as a security
      alert.
     
          RATIONALE: [...]

  4.  When parsing the IPv6 header chain, if the packet is identified
      to be a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield
      MUST drop the packet, and ought to the packet drop event in an
      implementation-specific manner as a security alert.

  5.  In all other cases...

OLD
  The above rules require that if a packet is dropped due to this
  filtering policy, the packet drop event be logged in an
  implementation-specific manner as a security fault.  The logging
  mechanism SHOULD include a per -port drop counter dedicated to
  DHCPv6-Shield packet drops.
NEW
  The above indicates that if a packet is dropped due to this filtering
  policy, the packet drop event be logged in an implementation-specific
  manner as a security fault.  It is useful for the logging mechanism
  to include a per -port drop counter dedicated to DHCPv6-Shield packet
  drops.

[Ballot comment]
- We note that DHCPv6-Shield only mitigates only DHCPv6-based attacks
  against hosts.
Remove one "only"

-
OLD:
      DHCPv6-Shield MUST parse the entire IPv6 header chain present in
      the packet, to identify whether it is a DHCPv6 packet meant for a
      DHCPv6 client (i.e., a DHCPv6-server message).
NEW:
      DHCPv6-Shield implementations MUST parse the entire IPv6 header chain present in
      the packet, to identify whether it is a DHCPv6 packet meant for a
      DHCPv6 client (i.e., a DHCPv6-server message).

- As mentioned by Jürgen in his OPS-DIR review:
  Section 5 is titled "DHCPv6-Shield Implementation Advice". It uses
  RFC2129 MUST language and talks about criteria for compliance. Is
  "Advice" really the right word for this? Sounds a bit soft for what
  are actually implementation requirements.

Fernando propoped: The title was borrowed from a similar I-D for RA-Guard implementation. I
guess we could simply say "DHCPv6-Shield Implementation"?

I thought it was a good idea.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

BCP.

This document describes a mechanism for protecting hosts connected to
a switched network against rogue DHCPv6 servers [RFC3315].  This
mechanism is very similar to an established feature that is widely
used in the IPv4 world - DHCP snooping.

BCP is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document describes a mechanism for protecting hosts connected to
a switched network against rogue DHCPv6 servers.  This mechanism is
based on DHCPv6 packet-filtering at the layer-2 device at which the
packets are received.  A similar mechanism has been widely deployed
in IPv4 networks ('DHCP snooping'), and hence it is desirable that
similar functionality be provided for IPv6 networks.

Working Group Summary

This document received a fair bit of in-depth review from key members
of the WG. The WGLC concluded that this is useful information that is
presented in an easy to read format.

Document Quality

This document provides advice to IPv6 implementors for protecting
hosts connected to a switched network against rogue DHCPv6 servers.
There is a valid implementation of this functionality on Cisco
equipment. Everyone who reviewed and commented on this document agrees
that this is a significant security issue and that the mechanism that
this draft provides is easy to use given its similarity to a similar
feature (DHCP snooping) that has existed for IPv4 networks for a
while.

Personnel

Who is the Document Shepherd? Who is the Responsible Area Director?

Kiran Kumar Chittimaneni is the Document Shepherd. Joel Jaeggli is the
Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

A WGLC was initiated, and then extended to get additional review from
key WG members. The Shepherd believes that there is now sufficient
review, both in terms of volume, and expertise.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

The document is complete and ready for publication.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No need, we feel that the document was well reviewed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The document is well written and there are no specific concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG agreed that this is good work. We also got very detailed and
specific feedback from various folks in the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

== Outdated reference: A later version (-29) exists of draft-ietf-savi-dhcp-27

Our current thinking is that this is minor and can be updated after
any IETF LC comments are received.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA action requested or required. This matches the text of the document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Only idnits tool.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-opsec-dhcpv6-shield-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers) to Best Current Practice


The IESG has received a request from the Operational Security
Capabilities for IP Network Infrastructure WG (opsec) to consider the
following document:
- 'DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-12-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies a mechanism for protecting hosts connected to
  a switched network against rogue DHCPv6 servers.  The aforementioned
  mechanism is based on DHCPv6 packet-filtering at the layer-2 device
  at which the packets are received.  The aforementioned mechanism has
  been widely deployed in IPv4 networks ('DHCP snooping'), and hence it
  is desirable that similar functionality be provided for IPv6
  networks.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

BCP.

This document describes a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers [RFC3315].  This mechanism is very similar to an established feature that is widely used in the IPv4 world - DHCP snooping.

BCP is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document describes a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers.  This mechanism is based on DHCPv6 packet-filtering at the layer-2 device at which the packets are received.  A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks.

Working Group Summary

This document received a fair bit of in-depth review from key members of the WG. The WGLC concluded that this is useful information that is presented in an easy to read format.

Document Quality

This document provides advice to IPv6 implementors for protecting hosts connected to a switched network against rogue DHCPv6 servers. There is a valid implementation of this functionality on Cisco equipment. Everyone who reviewed and commented on this document agrees that this is a significant security issue and that the mechanism that this draft provides is easy to use given its similarity to a similar feature (DHCP snooping) that has existed for IPv4 networks for a while.

Personnel

Who is the Document Shepherd? Who is the Responsible Area Director?

Kiran Kumar Chittimaneni is the Document Shepherd. Joel Jaeggli is the Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

A WGLC was initiated, and then extended to get additional review from key WG members. The Shepherd believes that there is now sufficient review, both in terms of volume, and expertise.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

The document is complete and ready for publication.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No need, we feel that the document was well reviewed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The document is well written and there are no specific concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG agreed that this is good work. We also got very detailed and specific feedback from various folks in the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

== Outdated reference: A later version (-29) exists of draft-ietf-savi-dhcp-27

Our current thinking is that this is minor and can be updated after any IETF LC comments are received.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No IANA action requested or required. This matches the text of the document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Only idnits tool.