Subject: [Gen-art] Fwd: draft-ietf-savi-dhcp-30 posted

From: Elwyn Davies <[email-masked]>
Date: Fri, 12 Dec 2014 13:24:48 +0000

-------- Forwarded Message --------
Subject: draft-ietf-savi-dhcp-30 posted
Date: Thu, 4 Dec 2014 02:17:06 +0000
From: Fred Baker (fred) <[email-masked]>
To: Elwyn Davies <[email-masked]>, Kathleen Moriarty 
<[email-masked]>, Ted Lemon <[email-masked]>, 
[email-masked] 
<[email-masked]>, Ralph Droms (rdroms) 
<[email-masked]>, Barry Leiba <[email-masked]>

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.

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 12 Dec 2014 13:25:08 +0000

-------- Forwarded Message --------
Subject: Re: draft-ietf-savi-dhcp-30 posted
Date: Thu, 4 Dec 2014 14:12:46 +0000
From: Ralph Droms (rdroms) <[email-masked]>
To: Fred Baker (fred) <[email-masked]>
CC: Elwyn Davies <[email-masked]>, Kathleen Moriarty 
<[email-masked]>, Ted Lemon <[email-masked]>, 
[email-masked] 
<[email-masked]>, Barry Leiba 
<[email-masked]>

Responding to the open issue regarding temporary addresses...

On Dec 3, 2014, at 6:17 PM 12/3/14, Fred Baker (fred) <[email-masked]> 
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've sent a message to the document team that is working on RFC3315bis. 
  I don't know if this particular issue has already been identified for 
clarification.

I wrote to the document team:

>
> My recollection is that the intention for IA_TA is that the addresses in an IA_TA have lifetimes, but the client is not expected to renew the lease on the address.  That recollection is supported, in my opinion, by this paragraph from 22.5:
>
>   An IA_TA option does not include values for T1 and T2.  A client MAY
>   request that the lifetimes on temporary addresses be extended by
>   including the addresses in a IA_TA option sent in a Renew or Rebind
>   message to a server.  For example, a client would request an
>   extension on the lifetime of a temporary address to allow an
>   application to continue to use an established TCP connection.

I'll let you know what comes back from the document team.  We may end up 
taking the question to the dhc WG as a whole...

- Ralph

> [...]

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 12 Dec 2014 13:25:58 +0000

-------- Forwarded Message --------
Subject: Re: draft-ietf-savi-dhcp-30 posted
Date: Fri, 5 Dec 2014 01:19:41 +0000
From: Fred Baker (fred) <[email-masked]>
To: Elwyn Davies <[email-masked]>
CC: Kathleen Moriarty <[email-masked]>, Ted Lemon 
<[email-masked]>, [email-masked] 
<[email-masked]>, Ralph Droms (rdroms) 
<[email-masked]>, Barry Leiba <[email-masked]>

On Dec 4, 2014, at 3:58 PM, Elwyn Davies <[email-masked]> wrote:
>> 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.

For the record, I had a conversation with Ted, Ralph, and the folks 
doing 3315bis. There is in fact a lifetime on a IA_TA; this is described 
in 3315 section 22.6, where there are two lifetimes specific, and a rule 
for determining which lifetime applies. So Temporary Addresses have a 
specified lifetime. They agreed to clarify this in 3315bis.

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 12 Dec 2014 13:25:36 +0000

-------- Forwarded Message --------
Subject: Re: draft-ietf-savi-dhcp-30 posted
Date: Fri, 5 Dec 2014 00:44:45 +0000
From: Fred Baker (fred) <[email-masked]>
To: Elwyn Davies <[email-masked]>
CC: Kathleen Moriarty <[email-masked]>, Ted Lemon 

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-masked]> 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_EXPIRE
> These 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.
>>
>>
>> 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".
>
>>
>> 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.
>>
>> 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.
>
>>
>>> 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.
>>
> Yes indeed.  Thank goodness!  So this one is done.