-------- Forwarded Message -------- Subject: draft-ietf-savi-dhcp-30 posted Date: Thu, 4 Dec 2014 02:17:06 +0000 From: Fred Baker (fred) <[email protected]>To: Elwyn Davies <[email protected]>, Kathleen Moriarty <[email protected]>, Ted Lemon <[email protected]>, [email protected] <[email protected]>, Ralph Droms (rdroms) <[email protected]>, Barry Leiba <[email protected]>
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.
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?
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?
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) ?
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.
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.
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.
signature.asc
Description: PGP signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
