Source Address Validation Improvement (SAVI) Solution for DHCP
draft-ietf-savi-dhcp-34
Yes
(Ted Lemon)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Benoît Claise)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Spencer Dawkins)
Note: This ballot was opened for revision 29 and is now closed.
Ted Lemon Former IESG member
Yes
Yes
(for -31)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -29)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -32)
Unknown
Alissa Cooper Former IESG member
(was Discuss)
No Objection
No Objection
(2015-02-18 for -33)
Unknown
Thanks for addressing my DISCUSS and comments. I still think it's weird to say deployment is beyond the scope of the document in the text below, but Fred's explanation has cleared up my other comments on that one. Original comment: "Traffic from unprotected links should be checked by an unprotected system or [RFC2827] mechanisms. The generation and deployment of such a mechanism is beyond the scope of this document." I see a few problems with this text. In the first sentence I don't understand the idea that a check would be performed by a system _or_ a mechanism. What about a system that employs the mechanism specified in BCP 38? Furthermore, the text implies that there are cases where BCP 38 doesn't apply, which seems to undercut the actual guidance provided in BCP 38. This is further reinforced by the second sentence that indicates that the generation of a new mechanism (to replace BCP 38? it's not clear) is beyond the scope of this document. It's also redundant to say that deployment is beyond the scope of the document -- deployment is beyond the scope of all protocol specs. And I'm unclear on whether "unprotected system" means the same thing as "unprotected device" as defined in Section 3. I think both sentences could be replaced with the following: "The mechanism specified in RFC 2827 is required in those cases."
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2014-12-04 for -30)
Unknown
Thank you SO much for all the work in addressing my comments in version -30. Sections 6 and 7 make LOTS more sense to me now, and I think there's been a great general improvement in the document. These minor comments remain, but they are non-blocking, so handle them as you think best: -- Section 8.1 -- Data packets from attachments with the Validating attribute MUST be checked. Packet whose source IP address is a link-local address will not be checked. So, we will never have a packet whose source address is a link-local address, and that has the Validating attribute set, right? That doesn't *seem* right to me, but that's what those two statements imply. And when you say "checked", what does that checking imply? What is done when a packet is "checked"? -- Section 10 -- A few words of explanation would help here: it's not usually a good idea to throw a list at a reader, cold. Are these recommended values? Required values? How were they determined (is there operational data that tells us that these are good values)? Explain what you're giving the reader here. -- Section 11.1 -- In bullet (1) you say "This constant SHOULD be configured prudently to avoid Denial of Service attacks." This relates to my comment on Section 10: how can I know what is "prudent"? Can you give some guidance about how to determine whether I've chosen a prudent value, and whether and how to adjust my choice so I can comply with the SHOULD? (2) The Data Snooping Process may set up wrong bindings if the clients do not reply to the detection probes. This would benefit from a reference: NEW (2) The Data Snooping Process may set up wrong bindings if the clients do not reply to the detection probes (see Section 7.5.1.2). END
Benoît Claise Former IESG member
No Objection
No Objection
(for -32)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(2015-02-02 for -32)
Unknown
* Figure 1 and its supporting text is unclear until the reader gets all the way through Section 4.3.2. It may be useful to put a forward reference to 4.3.2 for the protection perimeter. * Section 4.2 says that a SAVI device does not filter DHCP messages. As the WG considered the interactions with this draft and draft-ietf-opsec-dhcpv6-shield? The filtering done by draft-ietf-opsec-dhcpv6-shield may be useful in bootstrapping the function described in this document. * Section 4.2.4 says "...in some scenarios, a DHCP client may use a DHCP address without the DHCP address assignment procedure being performed on its current attachment." Can you provide an example of such a scenario? * I agree with Barry's comments on sections 8.1, 10, and 11.1.
Jari Arkko Former IESG member
No Objection
No Objection
(2015-02-05 for -32)
Unknown
I would like to ensure that the state machine issues raised in the Gen-ART review are resolved. Can the sponsoring AD make sure that happens before the draft is approved?
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -32)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-02-03 for -32)
Unknown
Thank you very much for addressing my comments on the definition of trust for the trust attribute and on the perimeter scope. The privacy section looks good and I was glad to see the "SHOULD NOT log" for this function.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -32)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -32)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -32)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -32)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-02-05 for -32)
Unknown
- The IPR declaration [1] looks odd from here - the usual Cisco MAD clause seems missing from that but is present if you look at the "history" tab which links to [2]. Is that a tooling issue or related to the declaration? Was the full declaration visible to the WG? [1] https://datatracker.ietf.org/ipr/2373/ [2] https://www.ietf.org/ietf-ftp/IPR/cisco-ipr-draft-ietf-savi-dhcp-26.txt - 1, 2nd last para: "It is RECOMMENDED that the administration enable a SAVI solution for link-local addresses, e.g., SAVI-FCFS [RFC6620]." That seems wrong but more importantly to not belong here. This is not the document that tells you how to use the various savi options is it? (I see savi-mix is expired though?) - section 3, para 1: "unspoofable" is just not correct, MAC addresses are the canonical binding anchor and those are entirely spoofable. RFC7039 says that "This property, called a "binding anchor", must be verifiable in every packet that the host sends and harder to spoof than the host's IP source address itself." which is much better - why not re-use better definitions and not make old mistakes again? - section 3: binding entry limit: The passive voice here is odd in the sentence "Limiting the number..." Don't you need to say who enforces this how for the text to be useful? - 4.3.5 - the last MUST there is more general than just SAVI-DHCP so needs to be re-stated - Thanks for 11.6!