Subject: Re: [Gen-art] Gen-art telechat review of draft-ietf-savi-dhcp-32

From: Jari Arkko <[email-masked]>
Date: Thu, 5 Feb 2015 23:08:53 +0800

Many thanks for your careful review, Elwyn. I understand that there is an effort underway to resolve these issues (including your kind offer to help).

I think we need to see through that change before the final approval of this document.

Jari

On 01 Feb 2015, at 08:31, Elwyn Davies <[email-masked]> wrote:

> 
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at 
> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. 
> 
> Please wait for direction from your document shepherd 
> or AD before posting a new version of the draft. 
> 
> Document:  draft-ietf-savi-dhcp-32.txt
> Reviewer:  Elwyn Davies
> Review Date:  2015/01/30
> IETF LC End Date:  [2014/08/07]
> IESG Telechat date: 2015/02/05
> 
> Summary: 
> I regret to say that although the draft has considerably improved since I last reviewed it, there are still a number of significant issues that need to be addressed before it can be considered ready for the IESG.  My main concern for the technical quality of the document is the specification of the Data Snooping Process where the state machine is just not properly specified.  There are numerous more local problems.  I am unsure how significant the issue with temporary disconnections if the data snooping process has to be used repeatedly on a particular attachment point.  The various suggestions on limiting the rate of data snooping and the probabilistic back off may mean that the disconnection disrupts connections, whereas if the disconnection are only a couple of packets long, the usual congestion avoidance mechanisms will cover up the gap.  Likewise, in the likely deployment scenarios of SAVI-DHCP, fragmented DHCP messages may be a non-problem: However the issue should be noted.  Previous reviews have noted that the attribute setting requirements could be contradictory; this has not been fixed, although I think the points of conflict have moved.  I have suggested some text to cover the necessity for security protection of lease query transactions which were also noted previously.
> 
> Major issues: 
> ===========
> None
> 
> Minor issues: 
> ===========
> Temporary disconnections when Data Snooping Process is relevant:
> -----------------------------------------------------------------------------------------
> The intention in the Data Snooping process appears to be that when the state reaches BOUND, the state machine 'merges' with the DHCP Snooping Process machine and thereafter responds to snooped DHCP messages as if the BOUND state had been reached purely by snooping DHCP messages.
> 
> However, there is no guarantee, in the exceptional cases where the Data Snooping Process is invoked in the first place, that the SAVI device will 'see' any relevant DHCP messages after reaching the BOUND state since the lack of such messages is what triggered the Data Snooping Process in the first place.  Consequently, there is a significant likelihood that when the lease time (derived via lease querying) expires, the SAVI device won't have seen any of the DHCP messages that would indicate that the lease had been extended.   The timeout event will therefore trigger the removal of the SAVI binding.  Thereafter the messages from the attached device will be dropped at least until the Data Snooping Process can kick in again, assuming that the attached device still has a lease and the SAVI device is still not seeing the DHCP messages.
> 
> This will mean that a device managed exclusively by Data Snooping  will suffer periodic packet loss.  How much of an effect this will have on the attached device depends on the probabilistic process used to start the Data Snooping Process and the applications being run on it.  If only a couple of packets are lost then the disconnection will probably be no worse than the effects of temporary congestion and the user will likely be unaware.  Longer outages could be very irritating, depending on their frequency, and would be difficult to diagnose/explain to the user.
> 
> One possibility would be to remember that a binding anchor was initially set up by data snooping and turn up the Data Snooping Probability to one for a period after its lease timed out.  This would minimise the disconnection period at the expense of a little more complexity.
> 
> Note, also that if not all the packets go through the SAVI device, those not passing through will not be validated and could have spoofed source addresses.
> 
> I think these issues should be mentioned even if it is thought they do not need any action.
> 
> Fragmented DHCP messages:
> ---------------------------------------
> The brief mention of draft-ietf-opsec-dhcpv6-shield at the end of s4.2.2 triggered a thought about a potential problem for SAVI-DHCP that doesn't seem to be considered in the draft.  It is possible that the DHCP messages that savi-dhcp has to snoop on might be fragmented before they pass through the SAVI device.  Unlike the scenario in the "shield" draft, it is not sufficient for the SAVI device to consider only the first fragment in a v6 DHCP message as it needs to know what type of DHCP message is passing by and that is not guaranteed to be deducible from the first fragment.  It may well not be a frequent occurrence, but it should probably be brought out - AFAICS it can apply to both DHCPv4 and DHCPv6 - it seems likely that the SAVI device would have to defragment the DHCP message in order to analyse it, but I haven't looked into this in detail.
> 
> s4.1, para 3:
>>  Traffic from unprotected links should be
>>    checked by an unprotected system or [
>> RFC2827] mechanisms.
> What does "an unprotected system" imply?  Does "system" mean a (SAVI) technique and devices other than the DHCP scheme or just a device outside the protection perimeter.   I would have assumed that the protection scheme could also be implemented on the (DHCP) SAVI device in parallel with the DHCP scheme.  Some different words are needed but I am not sure what.
> 
> s4.2.3:
>> If it
>>    is FALSE, either the Trust attribute must be TRUE (so that bindings
>>    become irrelevant) or another SAVI mechanism such as SAVI-FCFS must
>>    be used on the point of attachment.
>> 
> Does the protection mechanism *have* to be another SAVI mechanism?  Would RFC 2827 not be an alternative?
> 
> s4.2.3 (DHCP-Snooping Attribute)/s4.2.4 (Data-Snooping Attribute)/s4.2.5(Validating Attribute):
> Last para of s4.2.3:
>    Whenever this attribute is set TRUE on a point of attachment, the
>    "Validating Attribute" MUST also be set TRUE.
> 
> Last para sf s4.2.4:
>    Whenever this attribute is set on an attachment, the "Validating
>    Attribute" MUST be set on the same attachment. 
> 
> Last para of s4.2.5:
> 
>    The expected use case is when SAVI is used to monitor but not block
>    unvalidated transmissions.  The network manager, in that case, may
>    set the DHCP-Snooping and/or Data-Snooping attribute TRUE but the
>    VALIDATING attribute FALSE.
> 
> These statements are inconsistent:
> - s4.2.3 says DHCP-Snooping == TRUE  => Validating == TRUE
> - s4.2.3 says Data-Snooping == TRUE  => Validating == TRUE
> - s4.2.5 says DHCP=Snooping == TRUE and/or Data-Snooping == TRUE allows 
>   VALIDATING to be TRUE or FALSE.
> 
> I believe the statements in s4.2.3 and s4.2.4 can be deleted.
> 
> s4.2.4, last para:
>> Since some networks
>>    require DHCP deployment and others avoid it, there is no obvious
>>    universal default value for the Data-Snooping Attribute.  However,
>>    note that deployment of SLAAC (and therefore SAVI-FCFS) is generally
>>    configuration-free, while the deployment of DHCP involves at minimum
>>    the deployment of a server.  Hence, the Data-Snooping Attribute
>>    should default to FALSE, and a mechanism should be implemented to
>>    conveniently set it to TRUE on all points of attachment for which the
>>    Trust attribute is FALSE.
>> 
> If this text remains as it is the acronym SLAAC needs to be expanded (probably back in s1).  However, introducing SLAAC at this point seems inappropriate.  SAVI-DHCP is specifically stated in s1 to be intended for 'pure DHCP scenarios'.  Further, it is not at all clear why the issue of zero-configuration or otherwise suddenly appears here.  I suggest that the second sentence is removed unless there is some really good reason that I have missed.  
> 
> It seems to me that maybe there is something to be said about indirectly connected hosts here.
> 
> Nits/editorial comments: 
> General: Both 'validate' and 'check' are used in the text.  'Validating' (as in 'Validating Attribute') appears to have the specific meaning of ensuring that the IP source address is legitimate, whereas 'checking' has a variety of more general meanings.  It would be wise to ensure that wherever ensuring that the process of ensuring the IP source address is legitimate the term 'Validating' is used (possibly with a capital letter) and check is used in all other cases.
> 
> General: s/LEASEQUERY_REPLY/LEASEQUERY-REPLY/ (7 places) [There are also 8 places where it is already right.]
> 
> s1, para 1, first sentence: (has two 'source's)
> OLD:
>    This document describes a fine-grained source IPv4 or IPv6 source
>    address validation mechanism.
> NEW:
>    This document describes a fine-grained source
>    address validation mechanism for IPv4 and IPv6 packets.
> 
> s1, para 1, sentence 4: 
> OLD:
> assigned to the other attachment points or invalid in the network.
> NEW:
> assigned to any other attachment point in or not associated with the network.
> 
> s1, para 1, sentence 6: s/If [RFC2827]/Whereas [RFC2827]/
> 
> s1, para 2, sentence 2: s/the header of data packet/on the IP header of data packets/
> 
> s1, para 2, sentence 3: s/a permanent block/the permanent blockage/
> 
> s1, para 3:
> OLD:
> The appropriate SAVI method must be used in those cases.
> NEW:
> An alternative SAVI method would have be used in those cases.
> 
> s1, para 3: s/Besides, this mechanism/This mechanism/
> 
> s1, para 3: s/enable a SAVI solution for link-local/deploy an alternative SAVI solution for link-local/
> 
> s1, last para:
> OLD:
> This mechanism works for DHCPv4-only, DHCPv6-only, or both DHCPv4 and  DHCPv6.
> NEW:
> This mechanism works for networks that use DHCPv4 only, DHCPv6 only, or both DHCPv4 and  DHCPv6.
> 
> s3, Client-Server messages, 6th bullet:  It would be good to distinguish this bullet for example making it a next level sub-list with no bullet.
> 
> s3, Direct attachment/Indirect attachment: s/e.g./i.e./ (one in each entry)
> 
> s3, Unprotected link/Protected link: I believe the intention is that these are links connected to SAVI devices. Hence: s/that the device/that the SAVI device/
> 
> s3, Cut Vertex: s/connected components/connected components in a (network) graph/
> 
> s3, Cut Vertex; s6.1, para 2; s7.1, 1st and 2nd  bullets: 
> s/DHCP snooping process[procedure]/DHCP Snooping Process/
> 
> s3, Detection message: "by the Data Snooping Process."  I think "by" should be "during" but  could be "that triggers".
> 
> s3: The various messages associated with the DHCP lease query process are not mentioned here.  It would probably be appropriate to add the DHCPv4 DHCPLEASEQUERY and DHCPv6 LEASEQUERY messages to the Client-Server set as they will occasionally be used by DHCP clients but are mostly used by SAVI devices in this context but should be allowed from clients.  On the other hand, it may be sensible to have a separate category for the lease query responses as treated specially on return flows - I am not quite sure which is best. However they are categorized they need to be filtered in the same way as Server-to-Client messages and only allowed on attachment points that have the Trust or DHCP-Trust attributes. 
> 
> s4.1, para 1: I assume that a SAVI protection perimeter could contain more than one DHCP server (I think the last para of s4.2 implies this).  In this case s/include a DHCP server/include at least one DHCP server/
> 
> s4.2.1, para 1:
>> Examples of a trusted binding
>>    anchor would be a port to another SAVI device,
>> 
> Surely an attachment that is trusted doesn't have a binding anchor just because it is trusted - and also because, with multiple source addresses expected on the link, a binding anchor is not relevant.  This is said in the second para of the section! I think s/trusted binding anchor/trusted attachment/.
> 
> s4.2.1, para 2:
> Two points:
> - Presumably the intention is that *no* messages from attached devices will be checked - singling out DHCP and 'data' messages is confusing - better something like 'any packets, including DHCP messages' would be better. Also I assume that 'checked' is a synonym for 'validated' here (see General point above)
> - Para 1 of s4.2.6 states that "there is no need to set DHCP-Trust to TRUE on an attachment point that sets Trust TRUE   It would be clearer if this was made explicit here. I suggest:
> OLD:
>    SAVI devices will not set up bindings for points of attachment with
>    the Trust attribute set TRUE; DHCP messages and data packets from
>    attached devices with this attribute will not be checked.  If the
>    DHCP Server-to-Client messages from attached devices with this
>    attribute can trigger the state transitions specified in Section 6
>    and Section 7, the corresponding processes in Section 6 and Section 7
>    will handle these messages.
> NEW:
>    SAVI devices will not set up bindings for points of attachment with
>    the Trust attribute set TRUE; no packets, including DHCP messages, from
>    devices with this attribute on their attachments will be validated.  However DHCP 
>    Server-to-Client messages will be snooped on attachment points with the Trust 
>    attribute set TRUE in the same way as if they had the DHCP-Trust attribute set (see 
>    Section 4.2.2) 
> 
> s4.2.2: "ports that are trusted would have it set TRUE."
>  As discussed in the previous comment Trust effectively implies DHCP-Trust.  Suggest changing this to:
> NEW:
>    attachment points that have Trust set TRUE are implicitly treated as if DHCP-Trust is TRUE.
> 
> s4.2.5, s8.1: s/VALIDATING/Validating/ (for consistency naming attributes)
> 
> s4.2.4, para 2: s/Data-Snooping process/Data Snooping Process/
> 
> s4.3.1, bullet #2: s/Each SAVI device only need/Each SAVI device only needs/
> 
> s4.3.1, last para: Add a sentence after sentence 1 to emphasise that incoming  DHCP Server-to-Client messages are filtered at the boundary.  Suggest:
>      DHCP server response messages incoming across the perimeter will be dropped 
>      (see Section 8).
> [Note: This needs to be more general as the DHCP Server-to-Client messages do not include LEASEQUERY responses and maybe some others.]
> 
> s4.3.2, item (4)/Figure 1: The link to Non-SAVI Device 2 is marked as "protected" in Fig 1 and according to s4.3.2, item(4) it appears that the attachment point of this device on  SAVI Device A would have Trust set to TRUE.  I would have thought this meant  Non-SAVI Device 2 was inside the perimeter, but Fig 1 show it outside.  Please explain what is going on, as some further text may be needed. 
> 
> s4.3.2, last para:
> OLD:
>    The DHCP-Trust attribute is only TRUE on the inside links of the perimeter.
> NEW:
>    The DHCP-Trust attribute is only TRUE on links inside the perimeter.
> 
> s4.3.3, para 1: s/guideline/guidelines/
> 
> s4.3.5, para 1: s/and the SAVI switch/and the SAVI device/ (as it isn't necessarily a switch).
> 
> s4.3.5, para 2: s/IP spoofing traffic/spoofed IP traffic/
> 
> s4.4, item (1): 
>> Address configuration.  For DHCPv4: the client of a SAVI device
>>        MUST have an IPv4 address.
>> 
> Comparing this with the following words for IPv6, I think this ought to be "For DHCPv4: the SAVI device MUST have an IPv4 address."  Otherwise it is really a non-sequitur, since if DHCPv4 is being used, presumably the idea is that the client will obtain an IPv4 address from the DHCP server - the text implies that it needs one even before it gets one via DHCPv4.
> 
> s4.4, item (2):  Add "A SAVI device may also require security parameters, such as pre-configured 
> keys to establish a secure connection for the Lease query process (see [RFC4388,RFC 5007]).
> connection 
> 
> s5, bullet #1: In the light of the discussion in s4.3.5:
> OLD:
> 
> s5, bullet #2 in second set: s/data-snooping/data snooping/
> OLD:
>    o  Binding Anchor(Anchor): the binding anchor, i.e., a physical and/
>       or link-layer property of the attachment.
> NEW:
>    o  Binding Anchor(Anchor): the binding anchor, i.e., one or more physical and/
>       or link-layer properties of the attachment.
> 
> s5, Figure 4: s/instance/example/ (2 places - sentence before figure and caption of figure)
> 
> s6.1, sentence 1: s/on the client's point of attachment./via the client's point of attachment./
> 
> s6.1, sentence 2: s/basis/assumption/
> 
> s6.3: It would be worth noting here: "The DHCP message categories (e.g., DHCPv4 Discover) defined in Section 3 are used extensively in the definitions of events and elsewhere in the state machine definition."
> 
> s6.3: Possibly add equivalent text to that in s7.4:
>> If an event will trigger the creation of a new binding entry, the binding entry limit on the binding anchor MUST NOT be exceeded.
> 
> s6.3.2, EVE_DHCP_LEASEQUERY: It would be worth noting that DHCPv4 DHCPLEASEQUERY is not used in the DHCP Snooping process to avoid confusion with s7.  Also since the LEASEQUERY should have been originated by the SAVI Device itself, the destination check should verify that the message is directed to this SAVI device  - and it should not be forwarded once it has been processed here.
> 
> s6.3.2:
>>    o  Attribute check: ...; the DHCP Client-Server messages should be from
>>       attachments with DHCP-Snooping attribute.
>> 
>>    o  Destination check: the DHCP Server-to-Client messages should be
>>       destined to attachments with DHCP-Snooping attribute.  ...
>> 
> If I understand correctly, SAVI DHCP will allow devices on protected links (e.g., Non-SAVI device 2 in Figure 1) to obtain an IP address via DHCP without triggering the binding anchor set up.  The rules cited above would mean that the DHCP interactions for these devices would not trigger events, which I think is intended.  It might be worth making this explicit (assuming I have it correct). [Check: Should certain messages of types that might have triggered events but didn't, because of the above checks, be logged?]
> 
> s6.4.1.1: Two issues:
>  - Refers to DHCPv4 Reboot.  This is not a message that triggers this event and so should not be mentioned.  
>  - Should the address in any IA's carried by the DHCPv6 Request message that can trigger this message also be copied into the BST? If so should it also refer to Figure 6?
> 
> s6.4.1.2:  Refers to DHCPv4 Request.  This is not a message that triggers this event and so should not be mentioned. 
> 
> s6.4.1.3: Three issues:
>  - Refers to DHCPv4 Request and DHCPv4 Reboot.  These are not messages that trigger this event and so should not be mentioned.  
>  - Should the address in any IA's carried by the DHCPv6 Solicitation message that can trigger this message also be copied into the BST?  If so should it also refer to Figure 6?
> 
> s6.4.3.7: The LEASEQUERY message is destined for this SAVI device.  It is not clear where it would be forwarded to (maybe some DHCPv6 infrastructure on the SAVI device?)
> 
> Figure 9 Caption and Figure 10 Caption: s/Transit/Transition/
> 
> s6.4.4/Figure 9/Figure 10: Events EVE_DHCP_RENEW and EVE_DHCP_REBIND are missing from the table, list and diagram.  They should be marked as cycling in the BOUND state.  Putting them in here is desirable so that it is consistent with the table/diagrams in s7.9 etc.
> 
> s7.1, para 1: s/two case when this does not work/two cases when this does not work/
> 
> s7.1, bullet #1: s/everyone/every one/; 
>                            s/passing by the SAVI device/passing through the SAVI device/
> 
> s7.1, bullet #2: s/turns broken/becomes broken/;
>                            s/as planned/some planned change/
> 
> s7.1, para after bullets: 
> OLD:
>    Data Snooping Process prevents permanently blocking legitimate
>    traffic in case of these two exceptions.
> NEW:
>    The Data Snooping Process can avoid the permanent blocking of legitimate
>    traffic in case one of these two exceptions occurs.
> 
> s7.1, next to last para: s/a conditional SHOULD/OPTIONAL/;
>         s/without the above exceptions/where the exceptions cannot occur/
> 
> s7.1, last para:  Mention that the probability of unmatched packets triggering the Data Snooping Process should be a configurable parameter of implementations.  Presumably the default should be zero so it is normally turned off. 
> 
> s7.2, last para: s/about this process is discussed is/concerning this process are discussed in/
> 
> s7.3: The way in which the Data Snooping process integrates with the DHCP Snooping Process is not explained until the very end of s7 (in s7.8) and even then very tersely.  I suggest adding the following to s7.3:
> NEW:
>     The Data Snooping Process provides an alternative path for binding entries 
>     to reach the BOUND state in the exceptional cases explained in Section 7.1 
>     when there are no DHCP messages that can be snooped by the SAVI device.
> 
>     In some of the exceptional cases (especially the dynamic topology case), by 
>     the time the binding has reached the BOUND state the DHCP messages may 
>     be passing through the SAVI device.  In this case the events driven by DHCP 
>     messages that are expected in the BOUND state in the DHCP Snooping Process 
>     may occur and the binding can be handled by the DHCP Snooping Process 
>     state machine.
> 
>     In any event, the lease expiry timeout event will occur even if no others do.  
>     This will cause the binding to be deleted and the state to logically return to 
>     NO_BIND state.  Either the DHCP or the Data Snooping Process will be
>     reinvoked if the lease is still place.  If DHCP messages are still not passing 
>     through the SAVI device, there will be a brief disconnection during which 
>     data packets passing through the SAVI device will be dropped.  The 
>     probabilistic initiation of the Data Snooping Process can then take over again 
>     and return the binding state to BOUND in due course.    
> 
> s7.4, para 1: s/In addition to EVE_DATA_LEASEQUERY and EVE_DHCP_REBIND,/In addition to EVE_DHCP_RENEW and EVE_DHCP_REBIND,/
> 
> s7.4, para 1:  To make the BOUND state consistent with the DHCP Snooping Process case, the events EVE_DHCP_RELEASE, EVE_DHCP_DECLINE, EVE_DHCP_REPLY, and EVE_DHCP_LEASEQUERY should also be processed in the BOUND state.  The actions in the BOUND state can be explained by a reference to s6.4.3 rather than having to repeat them in s7. 
> 
> s7.5-s7.7:  The textual description of the actions is not an accurate representation of the evolution of the state machine, primarily because the sending of the second neighbour detection and second lease query messages is shown in the wrong state.  This means that the detection messages would not be received in the expected states.  The way to fix this is to define three "functions" (as is normally done for state machines).    The functions would subsume the text about sending ARP/DAD messages in s7.5.1, the text about sending lease queries in s7.6.1 and sending ARP requests in s7.7.1.  A third intermediate state is needed to handle the three response messages or timeouts from the three remote messages.  As it stands, the actions after an UNMATCH event (s7.5.1) involve transmitting messages and waiting for responses or timeouts.  The text is unclear exactly when the transition to the DETECTION state occurs, and the EVE_ENTRY_EXPIRE actions in DETECTION (s7.6.1) do not handle the retransmission of the ARP/DAD requests (see s7.5.1) but set about sending lease queries.  The BST needs an expire counter entry to simplify the number of states.  The sequence (for v4) needs to go something like:
> [NO_BIND] UNMATCH recd and decided to act
> [NO_BIND] Set expiry count -> 0; Send ARP; Set timeout to  DETECTION_TIMEOUT; Transition to [DETECTION]
> [DETECTION] CONFLICT recd => abort and discard binding; Transition to [NO_BIND]
> [DETECTION] EXPIRY: Increment expiry count; 
>                          if count == 1: Send ARP; Set timeout to  DETECTION_TIMEOUT; Remain in state [DETECTION]; 
>                          else if count ==2: Send lease query; Set timeout to LEASEQUERY_DELAY; set count to 0; Transition to state [RECOVERY]
> ... and similar in state RECOVERY.. an extra state is needed to handle the ARP etc after successful lease query.
> 
> s7.5.1:
>>    This local conflict process SHOULD be performed.  If it is not
>>    performed, the state of the entry is set to RECOVERY, the lifetime is
>>    set to 2*MAX_LEASEQUERY_DELAY, and the lease query process specified
>>    in the following section will be performed directly.
>> 
> Under what circumstances would the local conflict process not be performed?
> If the sequence noted above is used, the lease query process can be triggered by  setting the expiry count to 0 and sending the lease query request before transitioning to state RECOVERY.
> 
> s7.6.1, item (1): s/A list of authorized DHCP servers are kept/A list of authorized DHCP servers is kept/
> 
> s7.8/s7.9/Figure 13/Figure 14: s/Transit/Transition/ (4 places)
> 
> s8: The filtering of DHCP messages needs to apply to the various lease query and lease query response messages.  The relevant messages need to be either added to the appropriate one from Client-Server and server-to-Client category, or a new category created and mentioned with the existing categories (see comment on s3 above).
> 
>   s9.1, para 2: s/attribute can be found/attributes can be found/
> 
> s9.2, para 1: s/discard legitimate/to discard legitimate/; s/Purely/Simply/; s/is of/is a/;
>                       s/considerable/may cause considerable/
> s9.2, last para:
> OLD:
>    Immediately after reboot, the SAVI device SHOULD restore binding
>    states from the non-volatile storage.  The system time of save
>    process MUST be stored.  After rebooting, the SAVI device MUST check
>    whether each entry has been obsolete by comparing the saved lifetime
>    and the difference between the current time and time when the binding
>    entry is established.
> NEW
>    Immediately after reboot, the SAVI device SHOULD restore the binding
>    states from the non-volatile storage.   Using the time when each binding 
>    entry was saved, the SAVI device should check whether the entry has 
>    become obsolete by comparing the saved lifetime and the difference 
>    between the current time and time when the binding entry was established.  
>    Obsolete entries which would have expired before the reboot MUST be removed.
> 
> s11.2:  This section adds additional states/events/actions into the state machine.  The link-down event and its consequences aren't really a security consideration.
> 
> s11.3: I am unclear how the processes described could lead to multiple binding anchors being established on the same SAVI device.  Could you quote an example please?  I am unsure how a client with multiple attachments could be using the same address on each of them.
> 
> s11:  As discussed on various previous occasions, lease query operations are considered security sensitive [RFC5007] [RFC4388].  It is recommended that an IPsec channel is opened to carry out lease query enquiries.   However, since the number of SAVI devices and DHCP servers/relays in a typical network is relatively small and they will all be under the control of a single administrative authority, keying material can be prepositioned out of band and used as necessary by SAVI devices that know the addresses of the DHCP entities.  This needs to be described in an extra section in s11.  It may also be the case that in some circumstances, the SAVI protection itself could be considered sufficient to obviate the need for using IPsec channels - however, that needs to be discussed and  I suggest that the authors consult with a security expert (i.e., not me) to decide what is appropriate.
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 10 Feb 2015 20:58:52 +0000

If I say nothing on a comment, you should find a corresponding change in -33.

I’m also picking up Alissa’s comments in this same email, as I will include the updated text and a diff, and ask that reviewers check the changes made to ensure I have done it correctly and not missed anything. I imagine we may have another round of discussion resulting from that. When we agree on this version, I’ll post the draft.

> On Jan 31, 2015, at 4:31 PM, Elwyn Davies <[email-masked]> wrote:
> 
> 

Yes, a facility designed to drop traffic it believes to be forged will probably do so from time to time, and a process such as the data snooping process might do it incorrectly. That said, any time routing in the network changes (signal fade, loss of a link in an STP network that causes another link to go active, etc), affected traffic will be lost. Yes, the data snooping process likely extends that by the RTT to the DHCP server on the Lease Query, and it’s possible that said RTT is actually two or three. I should think the application would have noticed a pause around the routing change and see the side-effect of SAVI here as a continuation of the same.

> Fragmented DHCP messages:

On this, we put a comment into the security considerations (11.8). We didn’t go into specifying DHCP reassembly (if DHCP is carried in IP, reassembly is already specified by that), but we note that this is “left for further study”.

> What does "an unprotected system" imply?  Does "system" mean a (SAVI) technique and devices other than the DHCP scheme or just a device outside the protection perimeter.   I would have assumed that…

An unprotected device. We changed the phrase to be precisely as found in the definitions, and added such a device to the figure referenced.

> I believe the statements in s4.2.3 and s4.2.4 can be deleted.
We did that.

> If this text remains as it is the acronym SLAAC needs to be expanded (probably back in s1).

> However, introducing SLAAC at this point seems inappropriate.  SAVI-DHCP is specifically stated in s1 to be intended for 'pure DHCP scenarios'.  Further, it is not at all clear why the issue of zero-configuration or otherwise suddenly appears here.  I suggest that the second sentence is removed unless there is some really good reason that I have missed.
> 

We removed the statement.

> General: Both 'validate' and 'check' are used in the text.  'Validating' (as in 'Validating Attribute') appears to have the specific meaning of ensuring that the IP source address is legitimate, wh…

We went through, and changed some instances of “validate” to “check” and vice versa, or added something about a “source address". One valicates source addresses; one checks other things such as fields in a DHCP message.

>    address validation mechanism for IPv4 and IPv6 packets.

ack

> This mechanism works for networks that use DHCPv4 only, DHCPv6 only, or both DHCPv4 and  DHCPv6.

ack to all of those.

> s3, Client-Server messages, 6th bullet:  It would be good to distinguish this bullet for example making it a next level sub-list with no bullet.

Unclear. "DHCP Client-Server message” is the fifth bullet, and "DHCP Server-to-Client message” is the sixth bullet. They are both at the highest level of list; the next level down lists individual DHCP messages. ???

> s3, Direct attachment/Indirect attachment: s/e.g./i.e./ (one in each entry)

ack

> s3, Unprotected link/Protected link: I believe the intention is that these are links connected to SAVI devices. Hence: s/that the device/that the SAVI device/

Well, no. The entire point with an unprotected link is that the SAVI device doesn’t see DHCP messages sent to the interface. Hence, it is either connected to a non-SVI device, or it is beyond an unprotected link.

We changed the word from “upstream/downstream” to “unprotected/protected” at your request. I you have a better word, please suggest it.

> s3, Detection message: "by the Data Snooping Process."  I think "by" should be "during" but  could be "that triggers".

Detection message: a Neighbor Solicitation or ARP message intended by the Data Snooping Process to detect a duplicate address.

> s3: The various messages associated with the DHCP lease query process are not mentioned here.  It would probably be appropriate to add the DHCPv4 DHCPLEASEQUERY and DHCPv6 LEASEQUERY messages to th…

ack

> s4.1, para 1: I assume that a SAVI protection perimeter could contain more than one DHCP server (I think the last para of s4.2 implies this).  In this case s/include a DHCP server/include at least…

In concept, yes. DHCP, however, assumes that there is exactly one server. If there are multiple servers, they need to make themselves appear to be one.

> Surely an attachment that is trusted doesn't have a binding anchor just because it is trusted - and also because, with multiple source addresses expected on the link, a binding anchor is not releva…

ack

> - Presumably the intention is that *no* messages from attached devices will be checked - singling out DHCP and 'data' messages is confusing - better something like 'any packets, including DHCP mess…

ack

> s4.3.2, item (4)/Figure 1: The link to Non-SAVI Device 2 is marked as "protected" in Fig 1 and according to s4.3.2, item(4) it appears that the attachment point of this device on  SAVI Device A wou…

I changed the graphic.

> If I understand correctly, SAVI DHCP will allow devices on protected links (e.g., Non-SAVI device 2 in Figure 1) to obtain an IP address via DHCP without triggering the binding anchor set up.

Trusted links, yes. Untrusted protected links *require* the SAVI device to set up a BST entry, and in the case of a non-SAVI switch, it would be highly advisable of the binding anchor included both the port the switch is on and the MAC address of the device using the IP address. The SAVI Device can’t tell the difference between a switch requesting an address and a device attached to the switch requesting an address.

> The rules cited above would mean that the DHCP interactions for these devices would not trigger events, which I think is intended.  It might be worth making this explicit (assuming I have it correct). [Check: Should certain messages of types that might have triggered events but didn't, because of the above checks, be logged?]
> 
> s6.4.1.1: Two issues:

As noted there, there is a case. If a device departs and the binding state is maintained, another system can mimic it by recreating in itself the binding anchor information. If the state is not maintained, it may need to be to be recovered using the Data Snooping process. This comment suggests that the trade-off may be best handled by keeping the state momentarily to see if it is simply a signal fade issue.

> s11.3: I am unclear how the processes described could lead to multiple binding anchors being established on the same SAVI device.  Could you quote an example please?  I am unsure how a client with…

We may need to discuss this with my Chinese colleagues.

> s11:  As discussed on various previous occasions, lease query operations are considered security sensitive [RFC5007] [RFC4388].  It is recommended that an IPsec channel is opened to carry out lease…

We now have a note on configuration that the SAVI device may need keying information. I remain at a loss to say why the reference to 4388/5007 didn’t cover this, why it needs to be stated here and not any of the other requirements noted in 4388/5007, and why it has a different requirement level (MUST vs RECOMMENDED) from 4388/5007. Recall that significant cain is raised when draft-ietf-v6ops-mobile-device-profile increases the requirement levels from those in RFCs 6434 and 7066; what makes this different? Hence, I have not added commentary (that seems superfluous) to section 11.

From Alissa:
> 
> ----------------------------------------------------------------------
> 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.

I removed the comment. The primary point is that such stuff is out of scope.

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

That could be a long discussion. I’m with you in theory. This is in fact the language that has been used throughout the lifetime of the draft, since 2009. Changing it at this point seems very late in the game. For the version, I’m leaving it unchanged.

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

The DHCP message goes through the attached equipment. I changed the wording. See if it works better for you.

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

“BCP 38” and “RFC 2827” differ in what way?

Recall, BTW, that BCP 38 differs from SAVI in a fundamental way. BCP 38 is about a filter applied by an upstream network to traffic from its customer, and is about the prefix used by the customer. SAVI is about something done in the switch that a host connects to, in the SAME network, and is about the *address* used by a specific host. BCP 38 doesn’t protect a network from itself, only from other networks. SAVI protects a network from itself. One could argue that a network that implements SAVI throughout doesn’t require BCP 38 upstream, as it will never generate messages that BCP 38 would drop. One can’t say anything like that about a network protected by BCP 38 not needing internal protection.

> 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 you have not understood the statement of the section. Maybe you can help me reword that better.

Here’s the concept. I have two switching domains. They might or might not have a router between them; for sake of argument, let’s imagine they do. They do have separate DHCP service - the addresses in one domain come from DHCP server 1 and go through that domain, and the addresses in the other come from DHCP server 2 and go through the other domain. The switch I’m thinking hard about right now is in the first domain, and the second domain is “somewhere else”, at least topologically. I can protect systems in the first domain, because the DHCP messages from DHCP Server 1 go through it and are therefore visible to the switches. From my perspective, I have done good things for the second domain as well; if I can now not present a threat to myself, I can’t hurt anyone else either. But I don’t know that about the second domain - traffic coming from there might have crossed the great unwashed backbone, for example. Sure, I can say (BCP 38 applied in reverse) that my traffic came from the backbone, the backbone gave me a default route, and therefore that traffic all matches said default route. That doesn’t tell me much about whether anything is spoofed or not; I just don’t know, and have no way of knowing.

What this is saying is that if I have no way to validate addresses from a neighboring domain, I have no way to validate them; that’s the point of “out of scope". I can earnestly hope that the neighboring domain implements BCP 38 or SAVI, but I may not have control over that either. That’s a problem I can’t solve in this domain.

> I think both sentences could be replaced with the following: "The
> mechanism specified in RFC 2827 is required in those cases."

Well, maybe. But it might also be a SAVI mechanism in the neighboring network. And then there’s the reverse BCP 38 thing - traffic arrived from the backbone. What does that actually tell me about its source addresses? I’m a great believer in BCP 38 where it makes sense. I would be very hesitant to require it where it doesn't.

> = Section 7.1 =
> "This is the case
>   stands when the SAVI device is persistently on the path(s)"
> 
> I think the "stands" is extraneous?

removed it.

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Feb 2015 18:22:56 -0500

> In concept, yes. DHCP, however, assumes that there is exactly one server. If there are multiple servers, they need to make themselves appear to be one.

Not true.  There can be an arbitrary number of DHCP servers.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 11 Feb 2015 00:32:13 +0000

Hi, Fred.

Thanks for the quick turn around.

After a quick check, I think we are almost there from my point of view.  
Couple of trivia that I spotted:

The captions of Figures  9, 10 and 14: s/Transit/Transition/

s7.9.2: I missed out the "Resulting state" line:
Add at the end:
     Resulting state: VERIFY (no change) - if IPv4 DHCPLEASEQUERY 
"chaddr" address does not match ARP Reply hardware address - or BOUND - 
otherwise.

I'll take a slightly slower look tomorrow and get back to you one way or 
the other by the start of your day (assuming you on PST at the moment).

Cheers,
Elwyn

On 10/02/2015 20:58, Fred Baker (fred) wrote:
 > I’m also picking up Alissa’s comments in this same email, as I will
 > include the updated text and a diff, and ask that reviewers check the
 > changes made to ensure I have done it correctly and not missed
 > anything. I imagine we may have another round of discussion resulting
 > from that. When we agree on this version, I’ll post the draft.
 >
 >> I am the assigned Gen-ART reviewer for this draft. For background
 >> on Gen-ART, please see the FAQ at <
 >> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
 >>
 >> Please wait for direction from your document shepherd or AD before
 >> posting a new version of the draft.
 >>
 >> Document:  draft-ietf-savi-dhcp-32.txt Reviewer:  Elwyn Davies
 >> Review Date:  2015/01/30 IETF LC End Date:  [2014/08/07] IESG
 >> Telechat date: 2015/02/05
 >>
 >> Summary: I regret to say that although the draft has considerably
 >> improved since I last reviewed it, there are still a number of
 >> significant issues that need to be addressed before it can be
 >> considered ready for the IESG.  My main concern for the technical
 >> quality of the document is the specification of the Data Snooping
 >> Process where the state machine is just not properly specified.
 >> There are numerous more local problems.  I am unsure how
 >> significant the issue with temporary disconnections if the data
 >> snooping process has to be used repeatedly on a particular
 >> attachment point.  The various suggestions on limiting the rate of
 >> data snooping and the probabilistic back off may mean that the
 >> disconnection disrupts connections, whereas if the disconnection
 >> are only a couple of packets long, the usual congestion avoidance
 >> mechanisms will cover up the gap.  Likewise, in the likely
 >> deployment scenarios of SAVI-DHCP, fragmented DHCP messages may be
 >> a non-problem: However the issue should be noted. Previous reviews
 >> have noted that the attribute setting requirements could be
 >> contradictory; this has not been fixed, although I think the points
 >> of conflict have moved.  I have suggested some text to cover the
 >> necessity for security protection of lease query transactions which
 >> were also noted previously.
 >>
 >> Major issues: =========== None
 >>
 >> Minor issues: =========== Temporary disconnections when Data
 >> Snooping Process is relevant:
 >> 
The intention in the Data Snooping process appears to be that when the 
state reaches BOUND, the state machine 'merges' with the DHCP Snooping 
Process machine and thereafter responds to snooped DHCP messages as if 
the BOUND state had been reached purely by snooping DHCP messages.
>>
 >> However, there is no guarantee, in the exceptional cases where the
 >> Data Snooping Process is invoked in the first place, that the SAVI
 >> device will 'see' any relevant DHCP messages after reaching the
 >> BOUND state since the lack of such messages is what triggered the
 >> Data Snooping Process in the first place.  Consequently, there is a
 >> significant likelihood that when the lease time (derived via lease
 >> querying) expires, the SAVI device won't have seen any of the DHCP
 >> messages that would indicate that the lease had been extended.
 >> The timeout event will therefore trigger the removal of the SAVI
 >> binding.  Thereafter the messages from the attached device will be
 >> dropped at least until the Data Snooping Process can kick in again,
 >> assuming that the attached device still has a lease and the SAVI
 >> device is still not seeing the DHCP messages.
 >>
 >> This will mean that a device managed exclusively by Data Snooping
 >> will suffer periodic packet loss.  How much of an effect this will
 >> have on the attached device depends on the probabilistic process
 >> used to start the Data Snooping Process and the applications being
 >> run on it.  If only a couple of packets are lost then the
 >> disconnection will probably be no worse than the effects of
 >> temporary congestion and the user will likely be unaware.  Longer
 >> outages could be very irritating, depending on their frequency, and
 >> would be difficult to diagnose/explain to the user.
 >>
 >> One possibility would be to remember that a binding anchor was
 >> initially set up by data snooping and turn up the Data Snooping
 >> Probability to one for a period after its lease timed out.  This
 >> would minimise the disconnection period at the expense of a little
 >> more complexity.
 >>
 >> Note, also that if not all the packets go through the SAVI device,
 >> those not passing through will not be validated and could have
 >> spoofed source addresses.
 >>
 > Yes, a facility designed to drop traffic it believes to be forged
 > will probably do so from time to time, and a process such as the data
 > snooping process might do it incorrectly. That said, any time routing
 > in the network changes (signal fade, loss of a link in an STP network
 > that causes another link to go active, etc), affected traffic will be
 > lost. Yes, the data snooping process likely extends that by the RTT
 > to the DHCP server on the Lease Query, and it’s possible that said
 > RTT is actually two or three. I should think the application would
 > have noticed a pause around the routing change and see the
 > side-effect of SAVI here as a continuation of the same.
 >
 >> Fragmented DHCP messages: ---------------------------------------
 >> The brief mention of draft-ietf-opsec-dhcpv6-shield at the end of
 >> s4.2.2 triggered a thought about a potential problem for SAVI-DHCP
 >> that doesn't seem to be considered in the draft.  It is possible
 >> that the DHCP messages that savi-dhcp has to snoop on might be
 >> fragmented before they pass through the SAVI device. Unlike the
 >> scenario in the "shield" draft, it is not sufficient for the SAVI
 >> device to consider only the first fragment in a v6 DHCP message as
 >> it needs to know what type of DHCP message is passing by and that
 >> is not guaranteed to be deducible from the first fragment.  It may
 >> well not be a frequent occurrence, but it should probably be
 >> brought out - AFAICS it can apply to both DHCPv4 and DHCPv6 - it
 >> seems likely that the SAVI device would have to defragment the DHCP
 >> message in order to analyse it, but I haven't looked into this in
 >> detail.
 >
 > On this, we put a comment into the security considerations (11.8). We
 > didn’t go into specifying DHCP reassembly (if DHCP is carried in IP,
 > reassembly is already specified by that), but we note that this is
 > “left for further study”.
 >
 >> s4.1, para 3:
 >>> Traffic from unprotected links should be checked by an
 >>> unprotected system or [ RFC2827] mechanisms.
 >> What does "an unprotected system" imply?  Does "system" mean a
 >> (SAVI) technique and devices other than the DHCP scheme or just a
 >> device outside the protection perimeter.   I would have assumed
 >> that the protection scheme could also be implemented on the (DHCP)
 >> SAVI device in parallel with the DHCP scheme.  Some different words
 >> are needed but I am not sure what.
 >
 > An unprotected device. We changed the phrase to be precisely as found
 > in the definitions, and added such a device to the figure
 > referenced.
 >
 >> s4.2.3:
 >>> If it is FALSE, either the Trust attribute must be TRUE (so that
 >>> bindings become irrelevant) or another SAVI mechanism such as
 >>> SAVI-FCFS must be used on the point of attachment.
 >>>
 >> s4.2.3 (DHCP-Snooping Attribute)/s4.2.4 (Data-Snooping
 >> Attribute)/s4.2.5(Validating Attribute): Last para of s4.2.3:
 >> Last para sf s4.2.4: Whenever this attribute is set on an
 >> attachment, the "Validating Attribute" MUST be set on the same
 >> attachment.
 >>
 >> Last para of s4.2.5:
 >>
 >> The expected use case is when SAVI is used to monitor but not
 >> block unvalidated transmissions.  The network manager, in that
 >> case, may set the DHCP-Snooping and/or Data-Snooping attribute TRUE
 >> but the VALIDATING attribute FALSE.
 >>
 >> These statements are inconsistent: - s4.2.3 says DHCP-Snooping ==
 >> TRUE  => Validating == TRUE - s4.2.3 says Data-Snooping == TRUE  =>
 >> Validating == TRUE - s4.2.5 says DHCP=Snooping == TRUE and/or
 >> Data-Snooping == TRUE allows VALIDATING to be TRUE or FALSE.
 >>
 >>> Since some networks require DHCP deployment and others avoid it,
 >>> there is no obvious universal default value for the Data-Snooping
 >>> Attribute.  However, note that deployment of SLAAC (and therefore
 >>> SAVI-FCFS) is generally configuration-free, while the deployment
 >>> of DHCP involves at minimum the deployment of a server.  Hence,
 >>> the Data-Snooping Attribute should default to FALSE, and a
 >>> mechanism should be implemented to conveniently set it to TRUE on
 >>> all points of attachment for which the Trust attribute is FALSE.
 >>>
 >> However, introducing SLAAC at this point seems inappropriate.
 >> SAVI-DHCP is specifically stated in s1 to be intended for 'pure
 >> DHCP scenarios'.  Further, it is not at all clear why the issue of
 >> zero-configuration or otherwise suddenly appears here.  I suggest
 >> that the second sentence is removed unless there is some really
 >> good reason that I have missed.
 >>
 >> Nits/editorial comments: General: Both 'validate' and 'check' are
 >> used in the text.  'Validating' (as in 'Validating Attribute')
 >> appears to have the specific meaning of ensuring that the IP source
 >> address is legitimate, whereas 'checking' has a variety of more
 >> general meanings.  It would be wise to ensure that wherever
 >> ensuring that the process of ensuring the IP source address is
 >> legitimate the term 'Validating' is used (possibly with a capital
 >> letter) and check is used in all other cases.
 >
 > We went through, and changed some instances of “validate” to “check”
 > and vice versa, or added something about a “source address". One
 > valicates source addresses; one checks other things such as fields in
 > a DHCP message.
 >
 >> General: s/LEASEQUERY_REPLY/LEASEQUERY-REPLY/ (7 places) [There are
 >> also 8 places where it is already right.]
 >>
 >> s1, para 1, first sentence: (has two 'source's) OLD: This document
 >> describes a fine-grained source IPv4 or IPv6 source address
 >> validation mechanism. NEW: This document describes a fine-grained
 >> source address validation mechanism for IPv4 and IPv6 packets.
 >
 > ack
 >
 >> s1, para 1, sentence 4: OLD: assigned to the other attachment
 >> points or invalid in the network. NEW: assigned to any other
 >> attachment point in or not associated with the network.
 >>
 >> s1, para 3: OLD: The appropriate SAVI method must be used in those
 >> cases. NEW: An alternative SAVI method would have be used in those
 >> cases.
 >>
 >> s1, para 3: s/enable a SAVI solution for link-local/deploy an
 >> alternative SAVI solution for link-local/
 >>
 >> s1, last para: OLD: This mechanism works for DHCPv4-only,
 >> DHCPv6-only, or both DHCPv4 and  DHCPv6. NEW: This mechanism works
 >> for networks that use DHCPv4 only, DHCPv6 only, or both DHCPv4 and
 >> DHCPv6.
 >
 > ack to all of those.
 >
 >> s3, Client-Server messages, 6th bullet:  It would be good to
 >> distinguish this bullet for example making it a next level sub-list
 >> with no bullet.
 >
 > Unclear. "DHCP Client-Server message” is the fifth bullet, and "DHCP
 > Server-to-Client message” is the sixth bullet. They are both at the
 > highest level of list; the next level down lists individual DHCP
 > messages. ???
 >
 >> s3, Unprotected link/Protected link: I believe the intention is
 >> that these are links connected to SAVI devices. Hence: s/that the
 >> device/that the SAVI device/
 >
 > Well, no. The entire point with an unprotected link is that the SAVI
 > device doesn’t see DHCP messages sent to the interface. Hence, it is
 > either connected to a non-SVI device, or it is beyond an unprotected
 > link.
 >
 > We changed the word from “upstream/downstream” to
 > “unprotected/protected” at your request. I you have a better word,
 > please suggest it.
 >
 >> s3, Cut Vertex; s6.1, para 2; s7.1, 1st and 2nd  bullets: s/DHCP
 >> snooping process[procedure]/DHCP Snooping Process/
 >>
 >> s3, Detection message: "by the Data Snooping Process."  I think
 >> "by" should be "during" but  could be "that triggers".
 >
 > Detection message: a Neighbor Solicitation or ARP message intended by
 > the Data Snooping Process to detect a duplicate address.
 >
 >> s3: The various messages associated with the DHCP lease query
 >> process are not mentioned here.  It would probably be appropriate
 >> to add the DHCPv4 DHCPLEASEQUERY and DHCPv6 LEASEQUERY messages to
 >> the Client-Server set as they will occasionally be used by DHCP
 >> clients but are mostly used by SAVI devices in this context but
 >> should be allowed from clients.  On the other hand, it may be
 >> sensible to have a separate category for the lease query responses
 >> as treated specially on return flows - I am not quite sure which is
 >> best. However they are categorized they need to be filtered in the
 >> same way as Server-to-Client messages and only allowed on
 >> attachment points that have the Trust or DHCP-Trust attributes.
 >
 > ack
 >
 >> s4.1, para 1: I assume that a SAVI protection perimeter could
 >> contain more than one DHCP server (I think the last para of s4.2
 >> implies this).  In this case s/include a DHCP server/include at
 >> least one DHCP server/
 >
 > In concept, yes. DHCP, however, assumes that there is exactly one
 > server. If there are multiple servers, they need to make themselves
 > appear to be one.
 >
 >> s4.2.1, para 1:
 >>> Examples of a trusted binding anchor would be a port to another
 >>> SAVI device,
 >>>
 >> Surely an attachment that is trusted doesn't have a binding anchor
 >> just because it is trusted - and also because, with multiple source
 >> addresses expected on the link, a binding anchor is not relevant.
 >> This is said in the second para of the section! I think s/trusted
 >> binding anchor/trusted attachment/.
 >
 > ack
 >
 >> s4.2.1, para 2: Two points: - Presumably the intention is that *no*
 >> messages from attached devices will be checked - singling out DHCP
 >> and 'data' messages is confusing - better something like 'any
 >> packets, including DHCP messages' would be better. Also I assume
 >> that 'checked' is a synonym for 'validated' here (see General point
 >> above)
 >
 > ack
 >
 >> - Para 1 of s4.2.6 states that "there is no need to set DHCP-Trust
 >> to TRUE on an attachment point that sets Trust TRUE   It would be
 >> clearer if this was made explicit here. I suggest: OLD: SAVI
 >> devices will not set up bindings for points of attachment with the
 >> Trust attribute set TRUE; DHCP messages and data packets from
 >> and Section 7, the corresponding processes in Section 6 and Section
 >> 7 will handle these messages. NEW: SAVI devices will not set up
 >> bindings for points of attachment with the Trust attribute set
 >> TRUE; no packets, including DHCP messages, from devices with this
 >> attribute on their attachments will be validated. However DHCP
 >> Server-to-Client messages will be snooped on attachment points with
 >> the Trust attribute set TRUE in the same way as if they had the
 >> DHCP-Trust attribute set (see Section 4.2.2)
 >>
 >> s4.2.2: "ports that are trusted would have it set TRUE." As
 >> discussed in the previous comment Trust effectively implies
 >> DHCP-Trust.  Suggest changing this to: NEW: attachment points that
 >> have Trust set TRUE are implicitly treated as if DHCP-Trust is
 >> TRUE.
 >>
 >> s4.3.1, last para: Add a sentence after sentence 1 to emphasise
 >> that incoming  DHCP Server-to-Client messages are filtered at the
 >> boundary.  Suggest: DHCP server response messages incoming across
 >> the perimeter will be dropped (see Section 8). [Note: This needs to
 >> be more general as the DHCP Server-to-Client messages do not
 >> include LEASEQUERY responses and maybe some others.]
 >>
 >> s4.3.2, item (4)/Figure 1: The link to Non-SAVI Device 2 is marked
 >> as "protected" in Fig 1 and according to s4.3.2, item(4) it appears
 >> that the attachment point of this device on  SAVI Device A would
 >> have Trust set to TRUE.  I would have thought this meant Non-SAVI
 >> Device 2 was inside the perimeter, but Fig 1 show it outside.
 >> Please explain what is going on, as some further text may be
 >> needed.
 >
 > I changed the graphic.
 >
 >> s4.3.2, last para: OLD: The DHCP-Trust attribute is only TRUE on
 >> the inside links of the perimeter. NEW: The DHCP-Trust attribute is
 >> only TRUE on links inside the perimeter.
 >>
 >> Comparing this with the following words for IPv6, I think this
 >> ought to be "For DHCPv4: the SAVI device MUST have an IPv4
 >> address."  Otherwise it is really a non-sequitur, since if DHCPv4
 >> is being used, presumably the idea is that the client will obtain
 >> an IPv4 address from the DHCP server - the text implies that it
 >> needs one even before it gets one via DHCPv4.
 >>
 >> s4.4, item (2):  Add "A SAVI device may also require security
 >> parameters, such as pre-configured keys to establish a secure
 >> connection for the Lease query process (see [RFC4388,RFC 5007]).
 >> connection
 >>
 >> s5, bullet #1: In the light of the discussion in s4.3.5: OLD:
 >>
 >> s5, bullet #2 in second set: s/data-snooping/data snooping/ OLD: o
 >> Binding Anchor(Anchor): the binding anchor, i.e., a physical and/
 >> or link-layer property of the attachment. NEW: o  Binding
 >> Anchor(Anchor): the binding anchor, i.e., one or more physical
 >> and/ or link-layer properties of the attachment.
 >>
 >> s6.3: It would be worth noting here: "The DHCP message categories
 >> (e.g., DHCPv4 Discover) defined in Section 3 are used extensively
 >> in the definitions of events and elsewhere in the state machine
 >> definition."
 >>
 >>> If an event will trigger the creation of a new binding entry, the
 >>> binding entry limit on the binding anchor MUST NOT be exceeded.
 >>
 >> s6.3.2, EVE_DHCP_LEASEQUERY: It would be worth noting that DHCPv4
 >> DHCPLEASEQUERY is not used in the DHCP Snooping process to avoid
 >> confusion with s7.  Also since the LEASEQUERY should have been
 >> originated by the SAVI Device itself, the destination check should
 >> verify that the message is directed to this SAVI device - and it
 >> should not be forwarded once it has been processed here.
 >>
 >> s6.3.2:
 >>> o  Attribute check: ...; the DHCP Client-Server messages should
 >>> be from attachments with DHCP-Snooping attribute.
 >>>
 >>> o  Destination check: the DHCP Server-to-Client messages should
 >>> be destined to attachments with DHCP-Snooping attribute.  ...
 >>>
 >> If I understand correctly, SAVI DHCP will allow devices on
 >> protected links (e.g., Non-SAVI device 2 in Figure 1) to obtain an
 >> IP address via DHCP without triggering the binding anchor set up.
 >
 > Trusted links, yes. Untrusted protected links *require* the SAVI
 > device to set up a BST entry, and in the case of a non-SAVI switch,
 > it would be highly advisable of the binding anchor included both the
 > port the switch is on and the MAC address of the device using the IP
 > address. The SAVI Device can’t tell the difference between a switch
 > requesting an address and a device attached to the switch requesting
 > an address.
 >
 >> The rules cited above would mean that the DHCP interactions for
 >> these devices would not trigger events, which I think is intended.
 >> It might be worth making this explicit (assuming I have it
 >> correct). [Check: Should certain messages of types that might have
 >> triggered events but didn't, because of the above checks, be
 >> logged?]
 >>
 >> s6.4.1.1: Two issues: - Refers to DHCPv4 Reboot.  This is not a
 >> message that triggers this event and so should not be mentioned. -
 >> Should the address in any IA's carried by the DHCPv6 Request
 >> message that can trigger this message also be copied into the BST?
 >> If so should it also refer to Figure 6?
 >>
 >> s6.4.1.2:  Refers to DHCPv4 Request.  This is not a message that
 >> triggers this event and so should not be mentioned.
 >>
 >> s6.4.1.3: Three issues: - Refers to DHCPv4 Request and DHCPv4
 >> Reboot.  These are not messages that trigger this event and so
 >> should not be mentioned. - Should the address in any IA's carried
 >> by the DHCPv6 Solicitation message that can trigger this message
 >> also be copied into the BST?  If so should it also refer to Figure
 >> 6?
 >>
 >> s6.4.3.7: The LEASEQUERY message is destined for this SAVI device.
 >> It is not clear where it would be forwarded to (maybe some DHCPv6
 >> infrastructure on the SAVI device?)
 >>
 >> s6.4.4/Figure 9/Figure 10: Events EVE_DHCP_RENEW and
 >> EVE_DHCP_REBIND are missing from the table, list and diagram.  They
 >> should be marked as cycling in the BOUND state.  Putting them in
 >> here is desirable so that it is consistent with the table/diagrams
 >> in s7.9 etc.
 >>
 >> s7.1, bullet #1: s/everyone/every one/; s/passing by the SAVI
 >> device/passing through the SAVI device/
 >>
 >> s7.1, bullet #2: s/turns broken/becomes broken/; s/as planned/some
 >> planned change/
 >>
 >> s7.1, para after bullets: OLD: Data Snooping Process prevents
 >> permanently blocking legitimate traffic in case of these two
 >> exceptions. NEW: The Data Snooping Process can avoid the permanent
 >> blocking of legitimate traffic in case one of these two exceptions
 >> occurs.
 >>
 >> s7.1, last para:  Mention that the probability of unmatched packets
 >> triggering the Data Snooping Process should be a configurable
 >> parameter of implementations.  Presumably the default should be
 >> zero so it is normally turned off.
 >>
 >> s7.3: The way in which the Data Snooping process integrates with
 >> the DHCP Snooping Process is not explained until the very end of s7
 >> (in s7.8) and even then very tersely.  I suggest adding the
 >> following to s7.3: NEW: The Data Snooping Process provides an
 >> alternative path for binding entries to reach the BOUND state in
 >> the exceptional cases explained in Section 7.1 when there are no
 >> DHCP messages that can be snooped by the SAVI device.
 >>
 >> In some of the exceptional cases (especially the dynamic topology
 >> case), by the time the binding has reached the BOUND state the DHCP
 >> messages may be passing through the SAVI device.  In this case the
 >> events driven by DHCP messages that are expected in the BOUND state
 >> in the DHCP Snooping Process may occur and the binding can be
 >> handled by the DHCP Snooping Process state machine.
 >>
 >> In any event, the lease expiry timeout event will occur even if no
 >> others do. This will cause the binding to be deleted and the state
 >> to logically return to NO_BIND state.  Either the DHCP or the Data
 >> Snooping Process will be reinvoked if the lease is still place.  If
 >> DHCP messages are still not passing through the SAVI device, there
 >> will be a brief disconnection during which data packets passing
 >> through the SAVI device will be dropped.  The probabilistic
 >> initiation of the Data Snooping Process can then take over again
 >> s7.4, para 1: s/In addition to EVE_DATA_LEASEQUERY and
 >> EVE_DHCP_REBIND,/In addition to EVE_DHCP_RENEW and
 >> EVE_DHCP_REBIND,/
 >>
 >> s7.4, para 1:  To make the BOUND state consistent with the DHCP
 >> Snooping Process case, the events EVE_DHCP_RELEASE,
 >> EVE_DHCP_DECLINE, EVE_DHCP_REPLY, and EVE_DHCP_LEASEQUERY should
 >> also be processed in the BOUND state.  The actions in the BOUND
 >> state can be explained by a reference to s6.4.3 rather than having
 >> to repeat them in s7.
 >>
 >> s7.5-s7.7:  The textual description of the actions is not an
 >> accurate representation of the evolution of the state machine,
 >> primarily because the sending of the second neighbour detection and
 >> second lease query messages is shown in the wrong state. This
 >> means that the detection messages would not be received in the
 >> expected states.  The way to fix this is to define three
 >> "functions" (as is normally done for state machines). The
 >> functions would subsume the text about sending ARP/DAD messages in
 >> s7.5.1, the text about sending lease queries in s7.6.1 and sending
 >> ARP requests in s7.7.1.  A third intermediate state is needed to
 >> handle the three response messages or timeouts from the three
 >> remote messages.  As it stands, the actions after an UNMATCH event
 >> (s7.5.1) involve transmitting messages and waiting for responses or
 >> timeouts.  The text is unclear exactly when the transition to the
 >> DETECTION state occurs, and the EVE_ENTRY_EXPIRE actions in
 >> DETECTION (s7.6.1) do not handle the retransmission of the ARP/DAD
 >> requests (see s7.5.1) but set about sending lease queries.  The BST
 >> needs an expire counter entry to simplify the number of states.
 >> The sequence (for v4) needs to go something like: [NO_BIND] UNMATCH
 >> recd and decided to act [NO_BIND] Set expiry count -> 0; Send ARP;
 >> Set timeout to  DETECTION_TIMEOUT; Transition to [DETECTION]
 >> [DETECTION] CONFLICT recd => abort and discard binding; Transition
 >> to [NO_BIND] [DETECTION] EXPIRY: Increment expiry count; if count
 >> == 1: Send ARP; Set timeout to  DETECTION_TIMEOUT; Remain in state
 >> [DETECTION]; else if count ==2: Send lease query; Set timeout to
 >> LEASEQUERY_DELAY; set count to 0; Transition to state [RECOVERY]
 >> ... and similar in state RECOVERY.. an extra state is needed to
 >> handle the ARP etc after successful lease query.
 >>
 >> s7.5.1:
 >>> performed, the state of the entry is set to RECOVERY, the
 >>> lifetime is set to 2*MAX_LEASEQUERY_DELAY, and the lease query
 >>> process specified in the following section will be performed
 >>> directly.
 >>>
 >> Under what circumstances would the local conflict process not be
 >> performed? If the sequence noted above is used, the lease query
 >> process can be triggered by  setting the expiry count to 0 and
 >> sending the lease query request before transitioning to state
 >> RECOVERY.
 >>
 >> s8: The filtering of DHCP messages needs to apply to the various
 >> lease query and lease query response messages.  The relevant
 >> messages need to be either added to the appropriate one from
 >> Client-Server and server-to-Client category, or a new category
 >> created and mentioned with the existing categories (see comment on
 >> s3 above).
 >>
 >> s9.2, para 1: s/discard legitimate/to discard legitimate/;
 >> s/Purely/Simply/; s/is of/is a/; s/considerable/may cause
 >> considerable/ s9.2, last para: OLD: Immediately after reboot, the
 >> SAVI device SHOULD restore binding states from the non-volatile
 >> storage.  The system time of save process MUST be stored.  After
 >> rebooting, the SAVI device MUST check whether each entry has been
 >> obsolete by comparing the saved lifetime and the difference between
 >> the current time and time when the binding entry is established.
 >> NEW Immediately after reboot, the SAVI device SHOULD restore the
 >> binding states from the non-volatile storage.   Using the time when
 >> each binding entry was saved, the SAVI device should check whether
 >> the entry has become obsolete by comparing the saved lifetime and
 >> the difference between the current time and time when the binding
 >> entry was established. Obsolete entries which would have expired
 >> before the reboot MUST be removed.
 >>
 >> s11.2:  This section adds additional states/events/actions into the
 >> state machine.  The link-down event and its consequences aren't
 >> really a security consideration.
 >
 > As noted there, there is a case. If a device departs and the binding
 > state is maintained, another system can mimic it by recreating in
 > itself the binding anchor information. If the state is not
 > maintained, it may need to be to be recovered using the Data Snooping
 > process. This comment suggests that the trade-off may be best handled
 > by keeping the state momentarily to see if it is simply a signal fade
 > issue.
 >
 >> s11.3: I am unclear how the processes described could lead to
 >> multiple binding anchors being established on the same SAVI device.
 >> Could you quote an example please?  I am unsure how a client with
 >> multiple attachments could be using the same address on each of
 >> them.
 >
 >> s11:  As discussed on various previous occasions, lease query
 >> operations are considered security sensitive [RFC5007] [RFC4388].
 >> It is recommended that an IPsec channel is opened to carry out
 >> lease query enquiries.   However, since the number of SAVI devices
 >> and DHCP servers/relays in a typical network is relatively small
 >> and they will all be under the control of a single administrative
 >> authority, keying material can be prepositioned out of band and
 >> used as necessary by SAVI devices that know the addresses of the
 >> DHCP entities.  This needs to be described in an extra section in
 >> s11.  It may also be the case that in some circumstances, the SAVI
 >> protection itself could be considered sufficient to obviate the
 >> need for using IPsec channels - however, that needs to be discussed
 >> and  I suggest that the authors consult with a security expert
 >> (i.e., not me) to decide what is appropriate.
 >
 > We now have a note on configuration that the SAVI device may need
 > keying information. I remain at a loss to say why the reference to
 > 4388/5007 didn’t cover this, why it needs to be stated here and not
 > any of the other requirements noted in 4388/5007, and why it has a
 > different requirement level (MUST vs RECOMMENDED) from 4388/5007.
 > Recall that significant cain is raised when
 > draft-ietf-v6ops-mobile-device-profile increases the requirement
 > levels from those in RFCs 6434 and 7066; what makes this different?
 > Hence, I have not added commentary (that seems superfluous) to
 > section 11.
 >
 >
 > From Alissa:
 >>
>>
 >> = 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.  ...
 >>
 >> 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.
 >
>> "snooping" is prudent. I  would have thought something like
 >> "checking" or "verification" would have less baggage.
 >
 > That could be a long discussion. I’m with you in theory. This is in
 > fact the language that has been used throughout the lifetime of the
 > draft, since 2009. Changing it at this point seems very late in the
 > game. For the version, I’m leaving it unchanged.
 >
 >> = 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."
 >>
 >> 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?
 >
 > Recall, BTW, that BCP 38 differs from SAVI in a fundamental way. BCP
 > 38 is about a filter applied by an upstream network to traffic from
 > its customer, and is about the prefix used by the customer. SAVI is
 > about something done in the switch that a host connects to, in the
 > SAME network, and is about the *address* used by a specific host. BCP
 > 38 doesn’t protect a network from itself, only from other networks.
 > SAVI protects a network from itself. One could argue that a network
 > that implements SAVI throughout doesn’t require BCP 38 upstream, as
 > it will never generate messages that BCP 38 would drop. One can’t say
 > anything like that about a network protected by BCP 38 not needing
 > internal protection.
 >
 >> 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.
 >
 > Here’s the concept. I have two switching domains. They might or might
 > not have a router between them; for sake of argument, let’s imagine
 > they do. They do have separate DHCP service - the addresses in one
 > domain come from DHCP server 1 and go through that domain, and the
 > addresses in the other come from DHCP server 2 and go through the
 > other domain. The switch I’m thinking hard about right now is in the
 > first domain, and the second domain is “somewhere else”, at least
 > topologically. I can protect systems in the first domain, because the
 > DHCP messages from DHCP Server 1 go through it and are therefore
 > visible to the switches. From my perspective, I have done good things
 > for the second domain as well; if I can now not present a threat to
 > myself, I can’t hurt anyone else either. But I don’t know that about
 > the second domain - traffic coming from there might have crossed the
 > great unwashed backbone, for example. Sure, I can say (BCP 38 applied
 > in reverse) that my traffic came from the backbone, the backbone gave
 > me a default route, and therefore that traffic all matches said
 > default route. That doesn’t tell me much about whether anything is
 > spoofed or not; I just don’t know, and have no way of knowing.
 >
 > What this is saying is that if I have no way to validate addresses
 > from a neighboring domain, I have no way to validate them; that’s the
 > point of “out of scope". I can earnestly hope that the neighboring
 > domain implements BCP 38 or SAVI, but I may not have control over
 > that either. That’s a problem I can’t solve in this domain.
 >
 > Well, maybe. But it might also be a SAVI mechanism in the neighboring
 > network. And then there’s the reverse BCP 38 thing - traffic arrived
 > from the backbone. What does that actually tell me about its source
 > addresses? I’m a great believer in BCP 38 where it makes sense. I
 > would be very hesitant to require it where it doesn't.
 >
 >> = Section 7.1 = "This is the case stands when the SAVI device is
 >> persistently on the path(s)"
 >>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 11 Feb 2015 00:45:01 +0000

> On Feb 10, 2015, at 3:22 PM, Ted Lemon <[email-masked]> wrote:
> 

Interesting. Not what Ralph tells me.

OK, the key question is then what I need to do in the document.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 11 Feb 2015 00:51:04 +0000

> On Feb 10, 2015, at 4:32 PM, Elwyn Davies <[email-masked]> wrote:
> 
> Hi, Fred.
> 
> After a quick check, I think we are almost there from my point of view.  Couple of trivia that I spotted:
> 

Hmm. Thought I got that.

>     Resulting state: VERIFY (no change) - if IPv4 DHCPLEASEQUERY "chaddr" address does not match ARP Reply hardware address - or BOUND - otherwise.
> 
> I'll take a slightly slower look tomorrow and get back to you one way or the other by the start of your day (assuming you on PST at the moment).

I (now) have both of these in my copy.

> > If I say nothing on a comment,
>       you should find a corresponding change
> 
>       > in -33.
> 
>       >
> 
>       >> On Jan 31, 2015, at 4:31 PM, Elwyn Davies
>       <[email-masked]> <mailto:[email-masked]>
> 
>       >> wrote:
> 
>       >>
> 
>       >>
> 
>       http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>>.
> 
>       >>
> 
>       >> I think these issues should be mentioned even if it is
>       thought they
> 
>       >> do not need any action.
> 
>       >
> 
>       >> Does the protection mechanism *have* to be another SAVI
>       mechanism?
> 
>       >> Would RFC 2827 not be an alternative?
> 
>       >>
> 
>       >> If this text remains as it is the acronym SLAAC needs to
>       be
> 
>       >> expanded (probably back in s1).
> 
>       >
> 
>       >> It seems to me that maybe there is something to be said
>       about
> 
>       >> indirectly connected hosts here.
> 
>       >
> 
>       >> s1, para 2, sentence 2: s/the header of data packet/on
>       the IP
> 
>       >> header of data packets/
> 
>       >>
> 
>       >> s1, para 2, sentence 3: s/a permanent block/the permanent
> 
>       >> blockage/
> 
>       >>
> 
>       >> s3, Direct attachment/Indirect attachment: s/e.g./i.e./
>       (one in
> 
>       >> each entry)
> 
>       >
> 
>       > ack
> 
>       >
> 
>       >> s3, Cut Vertex: s/connected components/connected
>       components in a
> 
>       >> (network) graph/
> 
>       >>
> 
>       s/DHCP
>       As
>       >> s4.2.5, s8.1: s/VALIDATING/Validating/ (for consistency
>       naming
> 
>       >> attributes)
> 
>       >>
> 
>       >> s4.3.1, bullet #2: s/Each SAVI device only need/Each SAVI
>       device
> 
>       >> only needs/
> 
>       >>
> 
>       >> s4.3.5, para 1: s/and the SAVI switch/and the SAVI
>       device/ (as it
> 
>       >> isn't necessarily a switch).
> 
>       >>
> 
>       >> s5, Figure 4: s/instance/example/ (2 places - sentence
>       before
> 
>       >> figure and caption of figure)
> 
>       >>
> 
>       >> s6.1, sentence 1: s/on the client's point of
>       attachment./via the
> 
>       >> client's point of attachment./
> 
>       >>
> 
>       >> s7.1, para 1: s/two case when this does not work/two
>       cases when
> 
>       >> this does not work/
> 
>       >>
> 
>       >> s7.2, last para: s/about this process is discussed
>       is/concerning
> 
>       >> this process are discussed in/
> 
>       >>
> 
>       >> s7.6.1, item (1): s/A list of authorized DHCP servers are
>       kept/A
> 
>       >> list of authorized DHCP servers is kept/
> 
>       >>
> 
>       > I removed the comment. The primary point is that such stuff
>       is out of
> 
>       > scope.
> 
>       >
> 
>       >>
>       > The DHCP message goes through the attached equipment. I
>       changed the
> 
>       > wording. See if it works better for you.
> 
>       >
> 
>       > I think you have not understood the statement of the section.
>       Maybe
> 
>       > you can help me reword that better.
> 
>       >
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Feb 2015 20:53:57 -0500

> OK, the key question is then what I need to do in the document.

The proposed change looked fine to me.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 11 Feb 2015 05:49:37 +0000

> s11.3: I am unclear how the processes described could lead to multiple binding anchors being established on the same SAVI device.  Could you quote an example please?  I am unsure how a client with…

This is one point I’m unclear on in all this. In the draft I sent earlier, this is actually 11.4. Could you clarify the case here?

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 11 Feb 2015 15:25:58 +0800

This could be removed.

I just discussed with Guang and we remember that it was about a comment in SAVI meetings year ago about network bond ( a scenario that multiple NIC cards with the same IP address).

Jun

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 12 Feb 2015 00:15:25 +0000

Hi Fred.

A few odds and ends only:

s1:  Did you answer the IESG point that MAC addresses are not 
sufficiently immutable?  Actually s4.3.5 does say that MAC addresses are 
spoofable ...

s1, next to last para (bottom of p4):  s/This mechanism is primarily 
designed for pure DHCP scenarios/SAVI-DHCP is primarily designed for 
pure DHCP scenarios/ (Its not clear what 'this' applies to - Could be 
the FCFS in the previous sentence).

s3:
OLD:
    o  DHCPv4 DHCPLEASEQUERY-REPLY: A response to a DHCPLEASEQUERY 
request.  [RFC4388]
NEW:
    o  DHCPv4 DHCPLEASEACTIVE: A response to a DHCPLEASEQUERY request.  
[RFC4388]

[There are also DHCPLEASEUNASSIGNED and DHCPLEASEUNKNOWN that have to be 
ignored.]

OLD:
    o  DHCPv6 DHCPLEASEQUERY-REPLY: A response to a LEASEQUERY request. 
[RFC5007]
NEW:
    o  DHCPv6 LEASEQUERY-REPLY: A response to a LEASEQUERY request. 
[RFC5007]

s10: Comments have been received that more explanation of the constants 
would be helpful.  Probably worth a few words on what each is used for.

Regards,
Elwyn

================================================================

Hi, Fred.

After a quick check, I think we are almost there from my point of 
view.Â  Couple of trivia that I spotted:

The captions of FiguresÂ  9, 10 and 14: s/Transit/Transition/

s7.9.2: I missed out the "Resulting state" line:
Add at the end:
Â Â Â  Resulting state: VERIFY (no change) - if IPv4 DHCPLEASEQUERY 
"chaddr" address does not match ARP Reply hardware address - or BOUND - 
otherwise.

Cheers,
Elwyn

Â
On 10/02/2015 20:58, Fred Baker (fred) wrote:
 > Iâm also picking up Alissaâs comments in this same email, as I will
 > from that. When we agree on this version, Iâll post the draft.
 >
 >> Document:Â  draft-ietf-savi-dhcp-32.txt Reviewer:Â  Elwyn Davies
 >> Review Date:Â  2015/01/30 IETF LC End Date:Â [2014/08/07] IESG
 >> considered ready for the IESG.Â  My main concern for the technical
 >> There are numerous more local problems.Â  I am unsure how
 >> attachment point.Â  The various suggestions on limiting the rate of
 >> mechanisms will cover up the gap.Â  Likewise, in the likely
 >> a non-problem: However the issue should be noted.Â Previous reviews
 >> of conflict have moved.Â  I have suggested some text to cover the
 >> Data Snooping Process in the first place.Â  Consequently, there is a
 >> binding.Â  Thereafter the messages from the attached device will be
 >> will suffer periodic packet loss.Â  How much of an effect this will
 >> run on it.Â  If only a couple of packets are lost then the
 >> temporary congestion and the user will likely be unaware.Â  Longer
 >> Probability to one for a period after its lease timed out.Â  This
 > to the DHCP server on the Lease Query, and itâs possible that said
 >> that doesn't seem to be considered in the draft.Â  It is possible
 >> fragmented before they pass through the SAVI device.Â Unlike the
 >> is not guaranteed to be deducible from the first fragment.Â  It may
 > didnât go into specifying DHCP reassembly (if DHCP is carried in IP,
 > âleft for further studyâ.
 >
 >> s4.1, para 3:
 >> What does "an unprotected system" imply?Â  Does "system" mean a
 >> device outside the protection perimeter.Â Â  I would have assumed
 >> SAVI device in parallel with the DHCP scheme.Â  Some different words
 >> block unvalidated transmissions.Â  The network manager, in that
 >> TRUEÂ  => Validating == TRUE - s4.2.3 says Data-Snooping == TRUEÂ  =>
 >>> Attribute.Â  However, note that deployment of SLAAC (and therefore
 >>> of DHCP involves at minimum the deployment of a server.Â  Hence,
 >> DHCP scenarios'.Â  Further, it is not at all clear why the issue of
 >> zero-configuration or otherwise suddenly appears here.Â I suggest
 >> used in the text.Â  'Validating' (as in 'Validating Attribute')
 >> general meanings.Â  It would be wise to ensure that wherever
 > We went through, and changed some instances of âvalidateâ 
to âcheckâ
 > and vice versa, or added something about a âsource address". One
 >> DHCPv6-only, or both DHCPv4 andÂ  DHCPv6. NEW: This mechanism works
 >> s3, Client-Server messages, 6th bullet:Â  It would be good to
 > Unclear. "DHCP Client-Server messageâ is the fifth bullet, and "DHCP
 > Server-to-Client messageâ is the sixth bullet. They are both at the
 > device doesnât see DHCP messages sent to the interface. Hence, it is
 > We changed the word from âupstream/downstreamâ to
 > âunprotected/protectedâ at your request. I you have a better word,
 > please suggest it.
 >
 >> s3, Cut Vertex; s6.1, para 2; s7.1, 1st and 2ndÂ bullets: s/DHCP
 >> s3, Detection message: "by the Data Snooping Process."Â I think
 >> "by" should be "during" butÂ  could be "that triggers".
 >
 >> process are not mentioned here.Â  It would probably be appropriate
 >> should be allowed from clients.Â  On the other hand, it may be
 >> implies this).Â  In this case s/include a DHCP server/include at
 >> least one DHCP server/
 >
 >> to TRUE on an attachment point that sets Trust TRUEÂ Â It would be
 >> attached devices with this attribute will not be checked.Â  If the
 >> attribute on their attachments will be validated.Â However DHCP
 >> DHCP-Trust.Â  Suggest changing this to: NEW: attachment points that
 >> that incomingÂ  DHCP Server-to-Client messages are filtered at the
 >> boundary.Â  Suggest: DHCP server response messages incoming across
 >> that the attachment point of this device onÂ  SAVI Device A would
 >> have Trust set to TRUE.Â  I would have thought this meantÂ  Non-SAVI
 >>> Address configuration.Â  For DHCPv4: the client of a SAVI device
 >> address."Â  Otherwise it is really a non-sequitur, since if DHCPv4
 >> s4.4, item (2):Â  Add "A SAVI device may also require security
 >> or link-layer property of the attachment. NEW: oÂ Binding
 >> confusion with s7.Â  Also since the LEASEQUERY should have been
 >> verify that the message is directed to this SAVI deviceÂ - and it
 >>> oÂ  Attribute check: ...; the DHCP Client-Server messages should
 >>> oÂ  Destination check: the DHCP Server-to-Client messages should
 >>> be destined to attachments with DHCP-Snooping attribute.Â  ...
 >>>
 > address. The SAVI Device canât tell the difference between a switch
 >> s6.4.1.1: Two issues: - Refers to DHCPv4 Reboot.Â  This is not a
 >> s6.4.1.2:Â  Refers to DHCPv4 Request.Â  This is not a message that
 >> Reboot.Â  These are not messages that trigger this event and so
 >> also be copied into the BST?Â  If so should it also refer to Figure
 >> 6?
 >>
 >> EVE_DHCP_REBIND are missing from the table, list and diagram.Â  They
 >> should be marked as cycling in the BOUND state.Â  Putting them in
 >> s7.1, last para:Â  Mention that the probability of unmatched packets
 >> parameter of implementations.Â  Presumably the default should be
 >> (in s7.8) and even then very tersely.Â  I suggest adding the
 >> messages may be passing through the SAVI device.Â  In this case the
 >> to logically return to NO_BIND state.Â  Either the DHCP or the Data
 >> Snooping Process will be reinvoked if the lease is still place.Â  If
 >> through the SAVI device will be dropped.Â  The probabilistic
 >> s7.4, para 1:Â  To make the BOUND state consistent with the DHCP
 >> also be processed in the BOUND state.Â  The actions in the BOUND
 >> s7.5-s7.7:Â  The textual description of the actions is not an
 >> second lease query messages is shown in the wrong state.Â  This
 >> expected states.Â  The way to fix this is to define three
 >> "functions" (as is normally done for state machines).Â Â Â  The
 >> ARP requests in s7.7.1.Â  A third intermediate state is needed to
 >> remote messages.Â  As it stands, the actions after an UNMATCH event
 >> timeouts.Â  The text is unclear exactly when the transition to the
 >> requests (see s7.5.1) but set about sending lease queries.Â  The BST
 >> Set timeout toÂ  DETECTION_TIMEOUT; Transition to [DETECTION]
 >> == 1: Send ARP; Set timeout toÂ  DETECTION_TIMEOUT; Remain in state
 >>> This local conflict process SHOULD be performed.Â  If it is not
 >> process can be triggered byÂ  setting the expiry count to 0 and
 >> lease query and lease query response messages.Â  The relevant
 >> storage.Â  The system time of save process MUST be stored.Â  After
 >> binding states from the non-volatile storage.Â Â  Using the time when
 >> s11.2:Â  This section adds additional states/events/actions into the
 >> state machine.Â  The link-down event and its consequences aren't
 >> Could you quote an example please?Â  I am unsure how a client with
 >> s11:Â  As discussed on various previous occasions, lease query
 >> lease query enquiries.Â Â  However, since the number of SAVI devices
 >> DHCP entities.Â  This needs to be described in an extra section in
 >> s11.Â  It may also be the case that in some circumstances, the SAVI
 >> andÂ  I suggest that the authors consult with a security expert
 > 4388/5007 didnât cover this, why it needs to be stated here and not
 >> that it is not filtered.Â  ...
 >>
 > That could be a long discussion. Iâm with you in theory. This is in
 > game. For the version, Iâm leaving it unchanged.
 >
 >> by an unprotected system or [RFC2827] mechanisms.Â  The generation
 > âBCP 38â and âRFC 2827â differ in what way?
 >
 > 38 doesnât protect a network from itself, only from other networks.
 > that implements SAVI throughout doesnât require BCP 38 upstream, as
 > it will never generate messages that BCP 38 would drop. One canât say
 > Hereâs the concept. I have two switching domains. They might or might
 > not have a router between them; for sake of argument, letâs imagine
 > other domain. The switch Iâm thinking hard about right now is in the
 > first domain, and the second domain is âsomewhere elseâ, at least
 > myself, I canât hurt anyone else either. But I donât know that about
 > default route. That doesnât tell me much about whether anything is
 > spoofed or not; I just donât know, and have no way of knowing.
 >
 > from a neighboring domain, I have no way to validate them; thatâs the
 > point of âout of scope". I can earnestly hope that the neighboring
 > that either. Thatâs a problem I canât solve in this domain.
 >
 > network. And then thereâs the reverse BCP 38 thing - traffic arrived
 > addresses? Iâm a great believer in BCP 38 where it makes sense. I

---

From: Fred Baker <[email-masked]>
Date: Wed, 11 Feb 2015 16:33:06 -0800

> On Feb 11, 2015, at 4:15 PM, Elwyn Davies <[email-masked]> wrote:
> 
> Hi Fred.
> 
> s1:  Did you answer the IESG point that MAC addresses are not sufficiently immutable?  Actually s4.3.5 does say that MAC addresses are spoofable ...

I didn’t. The issue is the same as with SVI-FCFS; the binding anchor is whatever we can make it. If the IESG wants to make an issue of the port+MAC Address, I’ll ask why it’s not an issue there.

Thanks, I’ll go through the rest and send a repeat tomorrow.

> s1, next to last para (bottom of p4):  s/This mechanism is primarily designed for pure DHCP scenarios/SAVI-DHCP is primarily designed for pure DHCP scenarios/ (Its not clear what 'this' applies to - Could be the FCFS in the previous sentence).
> 
> s3:
> OLD:
>    o  DHCPv4 DHCPLEASEQUERY-REPLY: A response to a DHCPLEASEQUERY request.  [RFC4388]
> NEW:
>    o  DHCPv4 DHCPLEASEACTIVE: A response to a DHCPLEASEQUERY request.  [RFC4388]
> 
> [There are also DHCPLEASEUNASSIGNED and DHCPLEASEUNKNOWN that have to be ignored.]
> 
> OLD:
>    o  DHCPv6 DHCPLEASEQUERY-REPLY: A response to a LEASEQUERY request. [RFC5007]
> NEW:
>    o  DHCPv6 LEASEQUERY-REPLY: A response to a LEASEQUERY request. [RFC5007]
> 
> s10: Comments have been received that more explanation of the constants would be helpful.  Probably worth a few words on what each is used for.
> 
> Regards,
> Elwyn
> 
> After a quick check, I think we are almost there from my point of view.Â  Couple of trivia that I spotted:
> 
> Â Â Â  Resulting state: VERIFY (no change) - if IPv4 DHCPLEASEQUERY "chaddr" address does not match ARP Reply hardware address - or BOUND - otherwise.
> 
>       > Iâ€™m also picking up Alissaâ€™s comments in this same email,
>       as I will
> 
>       > from that. When we agree on this version, Iâ€™ll post the
>       draft.
> 
>       >
> 
>       >> On Jan 31, 2015, at 4:31 PM, Elwyn Davies <[email-masked]> <mailto:[email-masked]>
> 
>       >> wrote:
> 
>       >>
> 
>       >>
> 
>       > to the DHCP server on the Lease Query, and itâ€™s possible
>       that said
> 
>       > didnâ€™t go into specifying DHCP reassembly (if DHCP is
>       carried in IP,
> 
>       > â€œleft for further studyâ€.
> 
>       >
> 
>       >> s4.1, para 3:
> 
>       > We went through, and changed some instances of â€œvalidateâ€
>       to â€œcheckâ€
> 
>       > and vice versa, or added something about a â€œsource
>       address". One
> 
>       > Unclear. "DHCP Client-Server messageâ€ is the fifth bullet,
>       and "DHCP
> 
>       > Server-to-Client messageâ€ is the sixth bullet. They are
>       both at the
> 
>       > device doesnâ€™t see DHCP messages sent to the interface.
>       Hence, it is
> 
>       > We changed the word from â€œupstream/downstreamâ€ to
> 
>       > â€œunprotected/protectedâ€ at your request. I you have a
>       better word,
> 
>       > please suggest it.
> 
>       >
> 
>       > address. The SAVI Device canâ€™t tell the difference between
>       a switch
> 
>       > 4388/5007 didnâ€™t cover this, why it needs to be stated here
>       and not
> 
>       > That could be a long discussion. Iâ€™m with you in theory.
>       This is in
> 
>       > game. For the version, Iâ€™m leaving it unchanged.
> 
>       >
> 
>       > â€œBCP 38â€ and â€œRFC 2827â€ differ in what way?
> 
>       >
> 
>       > 38 doesnâ€™t protect a network from itself, only from other
>       networks.
> 
>       > that implements SAVI throughout doesnâ€™t require BCP 38
>       upstream, as
> 
>       > it will never generate messages that BCP 38 would drop. One
>       canâ€™t say
> 
>       > Hereâ€™s the concept. I have two switching domains. They
>       might or might
> 
>       > not have a router between them; for sake of argument, letâ€™s
>       imagine
> 
>       > other domain. The switch Iâ€™m thinking hard about right now
>       is in the
> 
>       > first domain, and the second domain is â€œsomewhere elseâ€,
>       at least
> 
>       > myself, I canâ€™t hurt anyone else either. But I donâ€™t know
>       that about
> 
>       > default route. That doesnâ€™t tell me much about whether
>       anything is
> 
>       > spoofed or not; I just donâ€™t know, and have no way of
>       knowing.
> 
>       >
> 
>       > from a neighboring domain, I have no way to validate them;
>       thatâ€™s the
> 
>       > point of â€œout of scope". I can earnestly hope that the
>       neighboring
> 
>       > that either. Thatâ€™s a problem I canâ€™t solve in this
>       domain.
> 
>       >
> 
>       > network. And then thereâ€™s the reverse BCP 38 thing -
>       traffic arrived
> 
>       > addresses? Iâ€™m a great believer in BCP 38 where it makes
>       sense. I
> 
> <Attached Message Part.txt>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Feb 2015 20:59:41 -0500

> I didn’t. The issue is the same as with SVI-FCFS; the binding anchor is whatever we can make it. If the IESG wants to make an issue of the port+MAC Address, I’ll ask why it’s not an issue there.

I think the answer to this is simply that the security of DHCP is our of scope for this document.   This document explains how to filter out unauthorized uses of source IP addresses in the context of DHCP.   RFC 3315 provides a mechanism for securing DHCP messages, although it is not widely deployed because the key distribution problem is somewhat intractable; a document just passed last call in the DHC working group that provides a public-key based security mechanism for DHCP that should address that problem, and at some point hopefully that will be deployable in SAVI-DHCP environments.   But the security of DHCP messages is simply not something _this_ document can address.