Source Address Validation Improvement (SAVI) Solution for DHCP
draft-ietf-savi-dhcp-34

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."

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

* 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.

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?

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.

- 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!