-------- Forwarded Message -------- Subject: Re: draft-ietf-savi-dhcp-30 posted Date: Fri, 5 Dec 2014 00:44:45 +0000 From: Fred Baker (fred) <[email protected]> To: Elwyn Davies <[email protected]>CC: Kathleen Moriarty <[email protected]>, Ted Lemon <[email protected]>, [email protected] <[email protected]>, Ralph Droms (rdroms) <[email protected]>, Barry Leiba <[email protected]>
Thanks. I’ll talk with my co-authors and see if we can get this sorted out. On Dec 4, 2014, at 3:58 PM, Elwyn Davies <[email protected]> wrote:
Hi, Fred, This version is a *great* improvement, especially as regards language issues. There are a few nits that I'll send in a separate email. Some points that are not covered by the discussion below: s4.3.2, bullets (1) and (2): Although it is now clearer from s4.2.5 why Validating might be a separate attribute, the configuration guidelines don't suggest that it could be set otherwise than the same as DHCP-Snooping which looks as if it gets us back to the previous situation that was pointed out in earlier reviews. Notes about why one might set Validation False but DHCP-Snooping True should be added here to complement the previous explanation of Validating.. s4.3.2/s4.3.3/s4.3.4/s8: s4.3.2:The perimeter is also a perimeter for DHCP messages. The DHCP-Trust attribute is only TRUE on the inside links of the perimeter. Only DHCP server-to-client messages originated within the perimeter are trusted.s4.3.3:Thus, the DHCP server A cannot be contained within the perimeter apart from manual configuration of the binding anchor. Another consideration on the placement is that if the DHCP server/ relay is not inside the perimeter, the SAVI devices may not be able to set up bindings correctly, because the SAVI devices may not be on the path between the clients and the server/relay, or the DHCP messages are encapsulated (e.g., Relay-reply and Relay-forward).s4.3.4:To configure such a perimeter, at minimum the DHCP messages from upstream networks MUST be ensured to be trustworthy. Achieving this is beyond the scope of this document.s8:For attachments with other attributes: DHCP Server-to-Client messages not from attachments with the DHCP- Trust attribute or Trust attribute MUST be discarded. For attachments with no attribute: DHCP Server-to-Client messages from such attachments MUST be discarded.I don't think the combination of these statements achieves consistency. It seems to say that "yes, you can have DHCP servers outside the perimeter" but then you can't set the DHCP-Trust attribute on the attachment, and BTW, we are going to punt on how you would make the connection trustworthy - the bit about manual configuration of a trust anchor doesn't seem to cover the situation since other DHCP servers *inside* the perimeter don't use trust anchors and the way s8 is written any DHCP Server-to-Client messages would get discarded anyway. This issue harks back to the IPsec text in -28 mentioned below, since I think the idea was that you might have an IPsec tunnel out to the DHCP server or maybe use IPsec on all DHCP connections. To partly answer the question below, there is no point in discussing IPsec in this context until the authors have their heads round the whole upstream DHCP Server question properly. And if "out of scope" is the answer then the IPsec question is moot. s6.4.4/s7.9:Timeout: EVE_ENTRY_EXPIREThese aliases are redundant since the event name is used in the state table. s7.7.1/s7.8/s7.8.3/s7.9: I don't understand why the EVE_ENTRY_EXPIRE timeout event is not observed (s7.8.3). The timeout period is set in s7.7.1 before transition to the BOUND state. In s7.8.3 nothing is said after EVE_ENTRY_EXPIRE. In s7.9 it is clear that once the state gets to BOUND it stays there. This doesn't seem right. s11.2: In bullet point (1) it should be clearer that the timer is in addition to the lease/anchor timeout (well I think it has to be) so that if the client comes back on line as in bullet (3) the lease/anchor timeout is back in action and presumably runs to the expiry it would have done in the absence of the whole off-link business. Reactivating or just having the two running in parallel - in fact it has to be this latter so that if the lease goes while the node is off-link it will be correctly unbound. - needs to be noted. Some notes on the issues below. Regards, Elwyn On 04/12/14 02:17, Fred Baker (fred) wrote:We have posted draft-ietf-savi-dhcp-30. In that we think we have address all of Kathleen’s, Ted’s, and Barry’s comments, and most of Elwyn’s. We have a few open issues that will need to be addressed in a -31 version. Depending on the guidance we receive, -30 could go for further wider review, or -31 could do that. We’re waiting for your guidance. One open issue has to do with what looks like an inconsistency in RFC 3315, which is being updated in dhc as we speak and we are in correspondence with Ralph about. This has to do with (Elwin’s comment) the lifetime of a temporary address assigned using DHCP. As we understand 3315 section 10, all IAs carry a lifetime for each address they carry. Section 12 says that the IA_TA carrying a temporary address does not contain a lifetime. Ralph tells us, in private email, that it does. We think that has to be addressed by dhc.I'll leave that one to Ralph and dhc.Another open issue has to do with the terms “upstream” and “downstream” as used by the document. In short, the question is whether the SAVI device can legitimately expect to see all DHCP messages related to a given host; a downstream device/link would see all such, and an upstream device/link would not necessarily see them all. That said, the terminology would appear to suggest that the SAVI domain is at the edge of a network, with no other separate SAVI domains beyond it, which may not be true. We discussed using the terms “protected” and “unprotected”, and would like reviewer advice: would that be an improvement? Are there other terms that might be preferable?How about "controlled (external)" and "uncontrolled (external)"? I think there is really a third category of "internal".RFC 5007 recommends that LEASEQUERY/LEASEQUERY_REPLY messages should be protected by IPsec...True. For the switch to send such a message to a DHCP server, either the switch must have an IPsec security association with the server, or the server needs to be able to accept a non-IPsec-protected message from the switch. Unless we can trigger the host to initiate the LEASEQUERY, we think this has to be handled operationally. What text would the reviewers recommend?Have you asked the Security ADs and the dhc WG how bad they would consider it to be if the LEASEQUERY interaction didn't go over an IPsec channel? My feeling is that you maybe throwing away quite a bit of the supposed gains from doing SAVI-DHCP if you don't protect the LEASEQUERY channel, but I am not an expert in this area. At the bare minimum the issue needs to be documented, irrespective of what the eventual recommendation or mandate is.. You can probably get away with manually configured keys since presumably there are not many boxes involved, but it does mean extra complexity in the SAVI devices.There used to be some discussions on IPSec issues( s11.5 in savi-dhcp-28). They are removed due to comments received. Should they be added in again(after revision) ?See the previous comments on the external DHCP server issue.To Elwyn’s remaining unaddressed comments: we think they require no action.The definitions in s3 and the descriptions of the need to distinguish between upstream and downstream links would appear to rule out the use of SAVI as currently specified in situations where transit traffic and destination traffic share the same link. Presumably this rules out quite a few wi-fi networks, for example IPv6 networks with multiple subnets per link and possibly situations where there are multiple routers in series.The question is whether DHCP messages go through the switch to the host in question. If we see the DHCP messages, we can create a binding for the host; if we don’t, we can’t. Hence, upstream links (paths to devices we may not see the DHCP messages for) cannot be protected by this model, and are precluded by configuring attributes on the relevant interfaces. We believe that the draft identifies the fact and specifies those links.I'm going to postpone judgement on this one until I have slept on it and reread the new version. It is still nagging at my brain that there are more complex situations where the scheme falls down.s1: The reference to RFC 2827 (aka BCP38) might better refer to the more extensive RFC 3704 (BCP 84) - and, in any case, use the BCP reference rather than the RFC to cover any future update.Speaking as one of the authors of RFC 3704. RFC 2827 (BCP 38) protects a network from spoofed traffic coming from outside of it (usually a customer) by asking whether the source address is reasonable, and drops the message if it is not. RFC 3704 (BCP 84) suggests routing solutions would enable a network to route traffic to an upstream ISP that will not drop it following BCP 38, and describes uRPF filtering, which is a form of routing-based filter that could be used to implement BCP 38. When the switch thinks it is reasonable to accept some given set of IP addresses from the set of hosts attached to a given port, and drops messages with other addresses, it is similar to BCP 38, not BCP 84.I'll accept that for the simple cases RFC 2827 is fine. After I have seen the authors' responses to the external DHCP server issue raised above, I reserve the right to revive the proposal.Specifying the Data-Snooping state machine as a modification of the DHCP-Snooping state machine is confusing.In -30 at least, the two FSMs are separate.Yes indeed. Thank goodness! So this one is done.
signature.asc
Description: PGP signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
