> On Feb 11, 2015, at 4:15 PM, Elwyn Davies <[email protected]> wrote: > > 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 ...
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 > > ================================================================ > > 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: > > 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 protected]> > <mailto:[email protected]> > > >> 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 > <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. > > > > > > 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. > > >>> > > >> 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. > > >> > > > We did that. > > > > > >> 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. > > > > > > We removed the statement. > > > > > >> 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 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. > > > > > > 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, 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". > > > > > > 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 > > >> 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. > > > > > > 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. > > >> > > >> 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. > > > > > > 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?) > > >> > > >> 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. > > > > > > 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. > > > > > > 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 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: > > >> > > >> > ---------------------------------------------------------------------- > > >> > > >> > 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/ > > >> > > >> > > <Attached Message Part.txt>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
