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

[Ballot comment]
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."

[Ballot comment]


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

[Ballot comment]
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?

[Ballot discuss]
I have one point I'd like to discuss that shouldn't be hard to resolve.

= Section 4.3.4 =
"In common deployment practice, the traffic from the unprotected
  network is treated as trustworthy, which is to say that it is not
  filtered.  ...

  To configure such a perimeter, at minimum the DHCP messages from
  unprotected networks MUST be ensured to be trustworthy. Achieving
  this is beyond the scope of this document."

The first sentence says that trustworthy == not filtered, then the later sentence says that messages MUST be ensured to be trustworthy. The implication could be that messages MUST not be filtered, but that seems backwards. On the other hand, it doesn't seem right to have a normative requirement that messages be "ensured to be trustworthy" somehow, using some unspecified mechanism, without really explaining what counts as trustworthy. I would suggest deleting the second paragraph altogether unless it can be made meaningful for a network operator.

[Ballot comment]
In general I question whether calling the procedures in this document "snooping" is prudent. I would have thought something like "checking" or "verification" would have less baggage.

= Section 3 =
In the definitions of Unprotected link and Protected link, what does it mean for a device to "see" a DHCP message to a host?

= Section 4.1 =
"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."

= Section 7.1 =
"This is the case
  stands when the SAVI device is persistently on the path(s)"

I think the "stands" is extraneous?

s/one feasible link-layer paths/one feasible link-layer path/

[Ballot comment]
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.

[Ballot comment]
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 thanks for putting in the SHOULD NOT log for this function.

[Ballot comment]
* 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.

[Ballot comment]
* 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?

[Ballot comment]
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

[Ballot discuss]
1. The shepherd writeup notes that the reference to RFC 7039 needs to be moved to informative.  This is at DISCUSS-level because no downref was mentioned in the last call.  But as part of this DISCUSS point, and before you make the reference informative: Is it really possible to understand this document without understanding what a binding anchor is (and, thus, without reading RFC 7039)?

2. In Section 4.3.5, if I understand the first paragraph correctly, you're saying that of the six types of binding anchors described in 7039, one of them -- the MAC address -- is insecure because it's too easily spoofed and one -- switch port -- is secure and recommended... and that the other four need more analysis before a recommendation can be made.  Is that correct?

The second paragraph then says that switch ports can be shared, and you recommend using an unshared binding anchor.  Is that correct?

When I put those together, I get a situation where the document can't give me any recommendation about what binding anchor to use (if my switch ports are shared).  Why is that not a failure of the spec?  Why is no analysys done, and recommendation made, with respect to the other four binding anchor types?

3. I think Sections 6 and 7 need quite a bit of work to be understandable and useful.  See my comments below for my suggestions -- but those are only suggestions.  The DISCUSS point is to get some sort of clarity there, and, of course, I'm happy to help if I can.

[Ballot comment]
Why does the document have a pre-5378 disclaimer?  (It would have been good for the shepherd writeup to cover this.)

Reminder: move the two references to internet drafts to informative.

In general, I note that there's a *lot* of English editing needed here (errors in number, misuse of articles, odd phrasing, and the like).  I'm not making the observation a DISCUSS point, because I think it's all stuff the RFC Editor will fix and probably get right, but (1) I hoped that having a native English speaker as an author would fix that, and (2) I urge Fred and Ted to give this a *very* close reading auring AUTH48.

-- Section 3 --

  CUT VERTEX: A cut vertex is 'any vertex whose removal increases the
  number of connected components'.

Is there some significance to (1) the fact that "CUT VERTEX" is in ALL CAPS, and (2) that it's not consistently so?

-- Section 4.1 --

  Networks are not isolated and traffic from other networks, i.e.,
  transit traffic specified in [RFC6620], may get into the network with
  SAVI-DHCP deployed through the upstream links.

It's a small point, and you can ignore it if you prefer, but I found the interruption of the "i.e." phrase to be jarring, and also to call into question whether you really meant "e.g."  It's better not to make the reader work that hard, so I suggest this:

NEW
  Networks are not isolated, and traffic from other networks (see
  "transit traffic" in Section 2.1 of [RFC6620]) may get into the
  network with SAVI-DHCP deployed through the upstream links.
END

-- Section 4.2 --

  Binding anchors associated with upstream links MAY have no attribute
  after configuration.

I don't understand this.  As written, it's not a properly a 2119 MAY: it sounds like it's saying something factual, like "binding anchors may be orange."  If this really is an interoperability directive, you need to re-word this to say who really has the option and what the option is.

-- Section 4.2.2 --

  It is NOT RECOMMENDED to configure this attribute on any
  indirect attachment point of the non-neighboring DHCP servers and
  relays, unless all the elements that can be reached through that
  attachment point can be trusted

You need to add "NOT RECOMMENDED" to the 2119 boilerplate in Section 2.

While I'm here:
  The implementation for DHCPv6 can refer to
  [I-D.ietf-opsec-dhcpv6-shield] for more details.

Implementations don't take well to personification.  The implementors are the target for this, so, "DHCPv6 implementors can...."

-- Section 4.2.5 --

  This attribute MUST be used together with "DHCP-Snooping Attribute"
  or "Data-Snooping Attribute".

Now, Sections 4.2.3 and 4.2.4 say:
  Whenever this attribute is set on an attachment, the "Validating
  Attribute" MUST be set on the same attachment.

What this says to me is this:
1. When a *-Snooping Attribute is set, you MUST set the Validating Attribute, but...
2. ...the Validating Attribute can also be set without regard to the *-Snooping Attributes, and...
3. ...I'm not sure what the statement in 4.2.5 means, other than that.

I have a feeling you mean to say this:
2. ...the Validating Attribute can only be set when one of the *-Snooping attributed is set.
3. (no 3 is needed now)

If that's the case, let me suggest making it very clear, with no room for interpretation:

NEW
  This attribute MUST NOT be set on an attachment unless one or
  both of the "DHCP-Snooping Attribute" and the "Data-Snooping
  Attribute" is also set on the same attachment.
END

-- Section 4.3.1 --

  Consider the example in Figure 1.  The protection perimeter is formed
  by SAVI Device A, B and C.  In this case, SAVI device B doesn't
  create a binding for client A.  However, because SAVI device A
  filters spoofing traffic from client A, SAVI device B can avoid
  receiving spoofing traffic from client A.

I think you're actually saying something stronger than "can avoid", and an English-usage issue is weakening it.  Maybe this (with a few tweaks in addition to the main point)?:

NEW
  Consider the example in Figure 1: The protection perimeter is formed
  by SAVI Devices A, B and C.  In this case, SAVI Device B doesn't
  create a binding for Client A, because they are not connected to each
  other.  However, because SAVI Device A does have a binding for Client
  A, and filters spoofing traffic from it, SAVI Device B benefits from
  that filtering and does not receive spoofing traffic from Client A.
END

-- Section 4.3.2 --
The title of this section is too weak: it's not a "guideline", it's a requirement, as you say with the "MUST".  I suggest you change the title to "SAVI-DHCP Perimeter Configuration Requiements", and change the other uses of "guideline" (two occurrences in Section 4.3.3) to "requirements" as well.

-- Section 4.3.3 --

  It is SUGGESTED to
  configure IPsec between the DHCP relay and the DHCP server in such
  case.

"SUGGESTED" is not a 2119 key word, and it's not a good idea to make it look like one.

I'm having a really hard time understanding this section, especially the fourth paragraph.  Perhaps it's just from lack of experience with DHCP server configuration... but please have someone who understands DHCP and is native with English take a close look at Section 4.3.3, and see if some work on it can help.

-- Section 4.4 --
In bullet 1, there are two MUST requirements, and then a "needs also".  Does that mean that a global IPv6 address is at a lesser requirement level than a link-local address?  Or should the third be "MUST" also, for consistency?

In bullet 2, what is the real interoperability requirement?  Storing the list seems more like an implementation thing.

-- Section 5 --
Is the BST a protocol thing, or an implementation thing?  It doesn't look like bindint entries from BSTs are ever sent on the wire, and that if I chose to keep my binding information in another manner, not in a five-column table, no other entity in the system would know nor care.  Or am I wrong about that?  Do I misunderstand?

The paragraph about IA: First, what is an IA?  It's never expanded nor defined.  Second please do some work on the language in that paragraph.

-- Section 6 --
I find this whole section, with its subsections, to be poorly organized and hard to follow, with no overall explanation of how it all fits together.  This would benefit from a couple/few paragraphs that give an overview of the state machine (certain messages trigger certain events under specified conditions, those events result in state changes, whatever) so that the subsequent sections have a context.  It would also benefit from re-thinking the organization of the information in the subsections, and adding enough introductory text to each subsection to explain where that subsection is taking us.  For example, I might think of it this way, as an outline (note that I'm not just suggesting reversing the order, but also adding explanatory text):

  6 - overall introduction and description of the state machine operation
  6.1 - rationale (but see below)
  6.2 - explanation that DHCP messages trigger events under certain conditions, and explanation of the conditions
  6.3 - list of events, and the messages that can trigger them
  6.4 - list of states, and an explanation of the overall state flow; include the table and diagram from the current Section 6.5 here
  6.4 subsections - list of state transitions and detailed explanations

In the 6.4 subsections, I would reorganize so that each major explanation is in its own subsection.  For example, for 6.4.1, something like this:
  6.4.1 From NO_BIND to INIT_BIND - list events that can cause this transition (and make them a bullet list, not "X/Y/Z", which seems harder to read)
  6.4.1.1 - actions if the event is EVE_DHCP_REQUEST or EVE_DHCP_SOLICIT_RC or EVE_DHCP_REBOOT (again, as a list)
  6.4.1.2 - actions if the event is EVE_DHCP_CONFIRM

Be sure you're clear about whether the message is forwarded.  In many places you say, "The message MUST be forwarded," but in other places you say nothing.  What does it mean when you say nothing?

Consider using indentation to make conditions and subconditions clear.  For example, in the current Section 6.4.3.2, you have "If the trigger event is EVE_DHCP_REPLY", and then under that, "If the message is [this or that]."  It might be easier to follow this if you use bullet lists, or perhaps hanging-indent lists for the "if the message is" parts.  Properly used white space is a significant aid to comprehension.  6.4.2.2 is another dense section with a lot of decision paths.  Try to help guide the reader through the decision paths, remembering that the reader doesn't understand this the way you do.

Some other comments on the existing subsections:

-- Section 6.1 --
This is another section that's very difficult to read, and that would greatly benefit from work on the English wording.

-- Section 6.2 --

  Following binding states present in this process and the
  corresponding state machine:

I can't parse that sentence.

-- Section 7 --
The subsections here appear to modify the state machine described in Section 6.  I don't understand why this is done separately, and it seems to throw the whole organization off yet again.  It seems to make it significantly more difficult to understand the whole state machine that you're describing.  Anyway, if this remains as a separate section, my oganizational comments about Section 6 apply here as well.

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

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-savi-dhcp-29, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

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:  (SAVI Solution for DHCP) to Proposed Standard


The IESG has received a request from the Source Address Validation
Improvements WG (savi) to consider the following document:
- 'SAVI Solution for DHCP'
  as Proposed Standard

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-08-07. 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 the procedure for creating a binding between
  a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI
  (Source Address Validation Improvements) device.  The bindings set up
  by this procedure is used to filter out packets with forged source IP
  address in DHCP scenario.  This mechanism is proposed as a complement
  to ingress filtering to provide finer-grained source IP address
  validation.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/2373/

(1) The type of RFC requested is Proposed Standard. This is the proper
type because this document describes specifications for a mechanism being
implemented and deployed. The type of RFC is indicated in the title page
header.

(2) Here is the Document Announcement Write-Up,

Technical Summary:

This document specifies the procedure for creating a binding between a
DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI (Source
Address Validation Improvements) device. The bindings set up by this
procedure is used to filter out packets with forged source IP address in
DHCP scenario. This mechanism is proposed as a complement to ingress
filtering to provide finer-grained source IP address validation.

Working Group Summary:

Even if IPR have been disclosed, there is no concern from the WG to move
forward this document as Proposed Standard.

Document Quality:

This document has been thorough reviewed.

Personnel:

The document shepherd is Jean-Michel Combes (jeanmichel.combes@gmail.com). The
Responsible Area Director is Ted Lemon (ted.lemon@nominum.com)

(3) The review of this document performed by the Document Shepherd
includes:

- Comments from IESG regarding the other SAVI documents (i.e.,
FCFS SAVI, SEND SAVI) are taken into account inside this document

- Specifications described inside this document are following,
when possible, the same framework as the other SAVI documents (i.e., FCFS
SAVI, SEND SAVI) to ease the implementation of many SAVI mechanism inside a
same SAVI device.

- A check of the English level (even if English is not the mother
tongue of the Document Shepherd).

(4) The Document Shepherd has no concern about the deph or breadth of the
reviews that have been performed.

(5) As the mechanism specified in this document is strongly based on
DHCPv4/DHCPv6, the dhc WG has been associated to the WGLC.

(6) The Document Shepherd has no specific concerns or issue with this
document.

(7) Each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
been filed.

(8) An IPR disclosure has been filed that references this document. After
the disclosure, a new WGLC has been launched to know if any member of the
WG would have concerns to move forward the document: there was no concern.

(9) The WG consensus behind this document is mainly based of the
agreement of a small group with others being silent.

(10) Nobody threatened an appeal or otherwise indicated extreme discontent.

(11) The check done with ID Nits tool is not successful: there is one
error.

(12) The document doesn’t need to meet any required format review criteria

(13) All references within this document have been identified as either
normative or informative but, as noted by the ID Nits check (cf. above), a
normative reference is in fact an Informational RFC.

(14) There are 2 normative references (i.e., ietf-opsec-dhcpv6-shield,
ietf-dhc-dhcpv4-over-dhcpv6) that are not ready for advancement. Finally,
the Document Shepherd believes these references should become informative
references as they don’t impact critically the mechanism specified in this
document.

(15) There is one downward normative reference (cf. ID Nits check). This
normative reference should become informative reference.

(16) The publication of this document will not change the status of any
existing RFC.

(17) There is no request for an action from the IANA.

(18) There is no request for an action from the IANA.

(19) There is no formal language inside this document expecting a specific
review from the Document Shepherd.

[Ballot discuss]
I believe the following can be resolved relatively easily with some additional text in the document...

1. Does section 8 describe the mechanism that a SAVI device must perform if it has been unable to snoop the DHCP traffic between a host and a DHCP server?  It appears that way in the document, but it would be good to explicitly state that early in the document when the discussion of topologies is being carried out.  This becomes important when arbitrary topologies do not provide a means for the SAVI device to eavesdrop on the DHCP traffic.

2. Section 12 refers to the "tentative address multicast group".  Do you really mean the Solicited Node Multicast address that is generated from the configured IPv6 unicast address?

This document has been significantly revised for readability and to address other Discuss positions from the previous IESG review.  It is now ready to go back on a telechat.

[Ballot discuss]

  This document needs significant rewrite to be clear enough to produce
  interoperable implementations.  This view is supported by the Gen-ART
  Review by Elwyn Davies supports this view, and it can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07297.html

[Ballot comment]
This document looks generally good.  I have a few, small, non-blocking comments:

Section 5.1, a very, very minor thing: I found myself laughing at this sentence: "The state field is used to identify state."  Maybe change it to something like, "The state field changes over time to identify the current state of the binding."  That fits in well with what you say two sentences later, about a state change.
---

Section 6.1: you say, "To filter bogus DHCP server message by default," using the vague term "bogus DHCP server message" for the first time.  The introduction tells me that you're using these bindings "to filter or identify packets with forged source IP address."  Is that what you mean by "bogus messages" here?  If so, maybe say "forged" instead of "bogus".  If there are other ways that a message can be bogus, other than having a forged address in it, maybe you could make that clearer, either here or in the introduction.
---

The third paragraph of section 6.4 is a good example of explaining something well, and heading off what might otherwise be a confusing point.  Thanks.
---

Section 7.4.1.2:
    The states of the corresponding entries are set to be BOUND. The
    lifetime of the entries MUST be set to be the lease time.

There's really no reason to have that "MUST" there.  You're specifying what goes into the table, and the second sentence should read just like the first -- it's normative, without the need for the "MUST" (use "are" instead of "MUST be").
---

Section 13.1:
    If one of the following conditions is satisfied, the security can be
    ensured.

I suggest wording that differently to state actively what it is that you're doing:
    Protection from this attack can be ensured by making sure that one
    of the following conditions is satisfied:
---

Section 13.4:
  This mechanism is designed in
  consideration that a node may move on the local ink, and a node may
  have multiple binding anchors.

It seems that "ink" is a typo for "link", but I find the sentence unclear in general.  Can you try to re-word it?

[Ballot discuss]
I'm taking the unusual position of posting a Discuss on a document
I am responsible for.  I've taken over this document from Jari.  Eric
Levy-Abegnoli raised some issues in e-mail to ietf.org:

http://www.ietf.org/mail-archive/web/savi/current/msg01778.html

The authors posted revisions to respond to Eric's e-mail:

http://www.ietf.org/mail-archive/web/savi/current/msg01779.html

I will hold the Discuss until rev -13 is published.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (SAVI Solution for DHCP) to Proposed Standard





The IESG has received a request from the Source Address Validation

Improvements WG (savi) to consider the following document:

- 'SAVI Solution for DHCP'

  as a Proposed Standard



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 2012-03-20. 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 the procedure for creating bindings between a

  DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a

  binding anchor [I-D.ietf-savi-framework] on SAVI (Source Address

  Validation Improvements) device. The bindings can be used to filter

  packets generated on the local link with forged source IP address.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/ballot/





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

I have looked at the new draft and thought about this problem for a while.

We are making progress, but are not done yet.

Section 13.6 should indicate the performance impacts or lack thereof to the overall DNA processes. For instance, I think that the use of link local source addresses in NS probes in RFC 6059 means that the DNAv6 process is not hampered at all. But it would be good to confirm this.

On the DNAv4 side, you need to do more work. First off, there are two possible impacts that SAVI DHCP could have on DNAv4. First, it could cause some probe packets to be dropped. That would be generally fine as false negatives are OK (but should be documented as slowing down DNAv4 acquisition process). But if you were to cause false positives or prevent the host from acquiring an address, that would be bad. Which is it?

I'm not sure why you say in 13.6 that the DHCP process is not mandatory in DNAv4. In general, the RFC was designed to provide an optimization. If the probing doesn't complete, the parallel DHCP process will complete (assuming the network is working at all).

Section 4 and 9.1 should clearly say that link local addresses are not checked by this implementations of this specification. (I think it is in fact OK to run the SAVI DHCP scheme without a SAVI SLAAC solution.)

Jari

I have reviewed this draft. I have to apologize that it has taken so long, and I know you are waiting for me on a number of other open issues in the working group. I've been more busy than usual with day job, as well as having many documents in my review queue.

The draft is in pretty good shape, but there are a couple of issues that we still need to work on.

Technical:

We need to have the DHC WG folks review this in detail. I am not expert enough in verifying that everything is correct, and while we've had some DHCP folk participate the work, I think more review would be useful. This is a general principle in fact with all DHCP-related work in the IETF: we often like to run parallel working group last calls in the home working group of a draft as well as in DHC WG. I have asked for this review to be started now.

I do not understand how the draft works with DNAv4 (RFC 4436) and the DHCP rebinding procedure. The draft seems to be saying that it does not support L2 mobility (either through something like radio moving to a different AP on a WLAN) or through physical re-attachment on a different port. I think that it is such a basic requirement that we need to support that.

Couldn't the SAVI device follow the new messages on the DHCP as well as the ARP messages from RFC 4436?

Would making Section 8 process mandatory to implement help?

> Because
> no lease time will be contained in the REPLY from DHCP server, the
> SAVI device MUST send a LEASEQUERY [RFC5007] message querying by IP
> address to All_DHCP_Relay_Agents_and_Servers multicast address
> [RFC3315] or a configured server address.

This seems problematic. Can't the lease time be recovered from earlier messages and stored in the SAVI data structures? Note that RFC 5007 requires typically special security solutions (e.g., IPsec) and sets high requirements on what the SAVI device must do with the DHCP server.

>      Discard IPv6 Neighbor Solicitation (NS) and IPv4 gratuitous ARP
>      whose source is not an address bound with the corresponding binding
>      anchor.

Please document if this has any implications for DNAv6 (RFC 6059).

>    Whenever a binding anchor with attribute SAVI-Validation turns down,
>    set a timer with OFFLINK_DELAY. Until the timer becomes zero, the
>    bindings with the binding anchor SHOULD be kept. As an exception, to
>    handle movement, if receiving DAD Neighbor Solicitation/Gratuitous
>    ARP request targeting at the address during OFFLINK_DELAY, the entry
>    MAY be removed.
>
>    ...
>
>    OFFLINK_DELAY              2s

This seems awfully short time, what is the number based on? Do we know what computers that go to short suspend state do when they wake up? Do they re-DHCP, use DNAv4/6, or just continue if the period was short enough?

Editorial:

>                          Figure 2 Instance of BST

First use of the abbreviation BST. Please expand somewhere.

>                          Figure 3 Instance of FT

As above.

> If there is enough binding
>      entry resource,

resources

>      If the binding anchor is switch port, there can be vulnerability in
>

a switch port

(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for
forwarding to the IESG for publication?

Jean-Michel Combes (jeanmichel.combes@gmail.com) is the Document
Shepherd, savi WG co-chair. He has done a review on the document and
believes it is ready to be forwarded to IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have any
concerns about the depth or breadth of the reviews that have been
performed?

The document has had adequate reviews by key WG members. The document
shepherd does not have any concerns regarding the depth or breadth of
the reviews received.

(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA, internationalization or XML?

As this document specifies a new security mechanism that could impact
legitimate traffic, a review from the Security Directorate should be
done.
As this document specifies a DHCP based mechanism, a review from dhc
WG members may be done.

(1.d) Does the Document Shepherd have any specific concerns or issues
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. Has an IPR disclosure related to this
document been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on this
issue.

Based on the previous worries from the IESG on other SAVI documents
about privacy issues (i.e. logging) and residential threats, a
thorough review of the document has been done concerning these topics.

No IPR disclosure related to this document has been filed.

(1.e) 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?

There is savi WG consensus behind the document.

(1.f) 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 entered into the ID
Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See the Internet-Drafts Checklist and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media type
and URI type reviews?

The document shepherd has personally verified that the document
satisfies all ID nits. The document does not need MIB doctor review.
The document does not contain any media and URI types.

(1.h) Has the document split its references into normative and
informative? 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 strategy for their completion?
Are there normative references that are downward references, as
described in [RFC3967]? If so, list these downward references to
support the Area Director in the Last Call procedure for them
[RFC3967].

References are split into normative and informative sections.
There are no normative references that are downward references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the IANA
registries clearly identified? If the document creates a new registry,
does it define the proposed initial contents of the registry and an
allocation procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?

This document has an IANA considerations section and no IANA
considerations that need to be taken care of.

(1.j) Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules,
MIB definitions, etc., validate correctly in an automated checker?

There are no such sections.

(1.k) 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 memo specifies the procedure for creating bindings between a
DHCPv4/DHCPv6 assigned source IP address and a binding anchor on SAVI
(Source Address Validation Improvements) device. The bindings can be
used to filter packets generated on the local link with forged source
IP address.

Working Group Summary
The normal WG process was followed. The document as it is now,
reflects WG consensus.

Document Quality
The document was thoroughly reviewed by Christian Vogt, Joel M.
Halpern, Eric Levy-Abegnoli, Alberto Garcia and Jean-Michel Combes.