DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers
draft-ietf-opsec-dhcpv6-shield-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-08-14
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-08-04
|
08 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-07-28
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-07-07
|
08 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-07-07
|
08 | (System) | RFC Editor state changed to EDIT |
2015-07-07
|
08 | (System) | Announcement was received by RFC Editor |
2015-07-06
|
08 | (System) | IANA Action state changed to No IC from In Progress |
2015-07-06
|
08 | (System) | IANA Action state changed to In Progress |
2015-07-06
|
08 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-07-06
|
08 | Cindy Morgan | IESG has approved the document |
2015-07-06
|
08 | Cindy Morgan | Closed "Approve" ballot |
2015-07-06
|
08 | Cindy Morgan | Ballot approval text was generated |
2015-07-06
|
08 | Joel Jaeggli | Ballot writeup was changed |
2015-07-06
|
08 | Joel Jaeggli | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2015-07-06
|
08 | Will LIU | New version available: draft-ietf-opsec-dhcpv6-shield-08.txt |
2015-07-02
|
07 | Jean Mahoney | Closed request for Telechat review by GENART with state 'No Response' |
2015-05-15
|
07 | Fernando Gont | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-05-15
|
07 | Fernando Gont | New version available: draft-ietf-opsec-dhcpv6-shield-07.txt |
2015-05-14
|
06 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup |
2015-05-14
|
06 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-05-13
|
06 | Terry Manderson | [Ballot comment] Thank you for the effort invested in this document. From my reading it appears that -06 addresses the discuss raised by Ted. |
2015-05-13
|
06 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2015-05-13
|
06 | Ben Campbell | [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 … [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.) |
2015-05-13
|
06 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2015-05-13
|
06 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2015-05-11
|
06 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2015-05-07
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Ben Campbell |
2015-05-07
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Ben Campbell |
2015-04-20
|
06 | Alissa Cooper | [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 … [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. |
2015-04-20
|
06 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2015-04-19
|
06 | Joel Jaeggli | Telechat date has been changed to 2015-05-14 from 2015-01-22 |
2015-02-25
|
06 | Fernando Gont | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-02-25
|
06 | Fernando Gont | New version available: draft-ietf-opsec-dhcpv6-shield-06.txt |
2015-02-07
|
05 | Ted Lemon | [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 … [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. |
2015-02-07
|
05 | Ted Lemon | [Ballot comment] This is the original text of this DISCUSS: This text makes sense, but I think it needs to be changed somewhat: 3. … [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. :) |
2015-02-07
|
05 | Ted Lemon | Ballot comment and discuss text updated for Ted Lemon |
2015-02-07
|
05 | Ted Lemon | Notification list changed to draft-ietf-opsec-dhcpv6-shield@ietf.org, opsec@ietf.org, draft-ietf-opsec-dhcpv6-shield.ad@ietf.org, draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org, kk.chittimaneni@gmail.com, opsec-chairs@ietf.org, brian.e.carpenter@gmail.com from "KK Chittimaneni" <kk.chittimaneni@gmail.com> |
2015-01-22
|
05 | Cindy Morgan | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2015-01-22
|
05 | Brian Haberman | [Ballot comment] I agree with Stephen's point and believe that Ted's suggested change of the default behavior is one way to address that issue. |
2015-01-22
|
05 | Brian Haberman | Ballot comment text updated for Brian Haberman |
2015-01-22
|
05 | Ted Lemon | [Ballot discuss] This text makes sense, but I think it needs to be changed somewhat: 3. When parsing the IPv6 header chain, if the … [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. :) |
2015-01-22
|
05 | Ted Lemon | [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon |
2015-01-22
|
05 | Stephen Farrell | [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 … [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/ ? |
2015-01-22
|
05 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-01-22
|
05 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-01-21
|
05 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2015-01-21
|
05 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-01-21
|
05 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-01-21
|
05 | Alissa Cooper | [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 … [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.) |
2015-01-21
|
05 | Alissa Cooper | [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 … [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. |
2015-01-21
|
05 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2015-01-21
|
05 | Kathleen Moriarty | [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: … [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 |
2015-01-21
|
05 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-01-21
|
05 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-01-21
|
05 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-01-20
|
05 | Pete Resnick | [Ballot comment] Abstract: This document specifies a Best Current Practice for the implementation of DHCPv6 Shield. No, this does not specify a Best … [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. |
2015-01-20
|
05 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2015-01-20
|
05 | Benoît Claise | [Ballot comment] - We note that DHCPv6-Shield only mitigates only DHCPv6-based attacks against hosts. Remove one "only" - OLD: DHCPv6-Shield MUST … [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. |
2015-01-20
|
05 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-01-19
|
05 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-01-19
|
05 | Fernando Gont | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-01-19
|
05 | Fernando Gont | New version available: draft-ietf-opsec-dhcpv6-shield-05.txt |
2015-01-09
|
04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2015-01-05
|
04 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-12-31
|
04 | Joel Jaeggli | IESG state changed to IESG Evaluation from Waiting for Writeup |
2014-12-31
|
04 | Joel Jaeggli | [Ballot comment] a dreft to be posted to address lc coments from ralph droms and Sheng Jiang |
2014-12-31
|
04 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2014-12-31
|
04 | Joel Jaeggli | Placed on agenda for telechat - 2015-01-22 |
2014-12-31
|
04 | Joel Jaeggli | Changed consensus to Yes from Unknown |
2014-12-31
|
04 | Joel Jaeggli | Ballot has been issued |
2014-12-31
|
04 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2014-12-31
|
04 | Joel Jaeggli | Created "Approve" ballot |
2014-12-31
|
04 | Joel Jaeggli | Ballot writeup was changed |
2014-12-31
|
04 | Joel Jaeggli | 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 … 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. |
2014-12-11
|
04 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Hannes Tschofenig. |
2014-12-01
|
04 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2014-11-24
|
04 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2014-11-24
|
04 | Amanda Baber | 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 … 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. |
2014-11-24
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jürgen Schönwälder. |
2014-11-20
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hannes Tschofenig |
2014-11-20
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hannes Tschofenig |
2014-11-18
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2014-11-18
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2014-11-17
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ben Campbell |
2014-11-17
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ben Campbell |
2014-11-17
|
04 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-11-17
|
04 | Amy Vezza | 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 … 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. |
2014-11-17
|
04 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-11-17
|
04 | Amy Vezza | Last call announcement was changed |
2014-11-16
|
04 | Joel Jaeggli | Last call was requested |
2014-11-16
|
04 | Joel Jaeggli | Last call announcement was generated |
2014-11-16
|
04 | Joel Jaeggli | Ballot approval text was generated |
2014-11-16
|
04 | Joel Jaeggli | Ballot writeup was generated |
2014-11-16
|
04 | Joel Jaeggli | IESG state changed to Last Call Requested from AD Evaluation |
2014-11-07
|
04 | Joel Jaeggli | IESG state changed to AD Evaluation from Publication Requested |
2014-11-02
|
04 | Chittimaneni Kk | 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 … 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. |
2014-11-02
|
04 | Chittimaneni Kk | Responsible AD changed to Joel Jaeggli |
2014-11-02
|
04 | Chittimaneni Kk | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2014-11-02
|
04 | Chittimaneni Kk | IESG state changed to Publication Requested |
2014-11-02
|
04 | Chittimaneni Kk | IESG process started in state Publication Requested |
2014-11-02
|
04 | Chittimaneni Kk | Intended Status changed to Best Current Practice from None |
2014-11-02
|
04 | Chittimaneni Kk | Changed document writeup |
2014-11-02
|
04 | Chittimaneni Kk | Notification list changed to "KK Chittimaneni" <kk.chittimaneni@gmail.com> |
2014-11-02
|
04 | Chittimaneni Kk | Document shepherd changed to KK Chittimaneni |
2014-07-01
|
04 | Fernando Gont | New version available: draft-ietf-opsec-dhcpv6-shield-04.txt |
2014-06-05
|
03 | Fernando Gont | New version available: draft-ietf-opsec-dhcpv6-shield-03.txt |
2014-02-03
|
02 | Fernando Gont | New version available: draft-ietf-opsec-dhcpv6-shield-02.txt |
2013-10-21
|
01 | Fernando Gont | New version available: draft-ietf-opsec-dhcpv6-shield-01.txt |
2012-12-12
|
00 | Fernando Gont | New version available: draft-ietf-opsec-dhcpv6-shield-00.txt |