Telechat Review of draft-ietf-savi-dhcp-32
review-ietf-savi-dhcp-32-genart-telechat-davies-2014-09-12-00
| Request | Review of | draft-ietf-savi-dhcp |
|---|---|---|
| Requested revision | No specific revision (document currently at 34) | |
| Type | Telechat Review | |
| Team | General Area Review Team (Gen-ART) (genart) | |
| Deadline | 2014-09-16 | |
| Requested | 2014-09-04 | |
| Authors | Jun Bi , Jianping Wu , Guang Yao , Fred Baker | |
| I-D last updated | 2014-09-12 | |
| Completed reviews |
Genart Last Call review of -??
by Elwyn B. Davies
Genart Last Call review of -?? by Elwyn B. Davies Genart Telechat review of -29 by Elwyn B. Davies (diff) Genart Telechat review of -29 by Elwyn B. Davies (diff) Genart Telechat review of -32 by Elwyn B. Davies (diff) |
|
| Assignment | Reviewer | Elwyn B. Davies |
| State | Completed | |
| Request | Telechat review on draft-ietf-savi-dhcp by General Area Review Team (Gen-ART) Assigned | |
| Reviewed revision | 32 (document currently at 34) | |
| Result | Ready w/nits | |
| Completed | 2014-09-12 |
review-ietf-savi-dhcp-32-genart-telechat-davies-2014-09-12-00
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.
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
<elwynd at dial.pipex.com>
>> 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.
>
> 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/
>>
>>
_______________________________________________
Gen-art mailing list
Gen-art at ietf.org
https://www.ietf.org/mailman/listinfo/gen-art