Subject: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope!

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 01 Sep 2009 17:00:12 -0400

So the deadline for BoF requests for the upcoming meeting is rather early
IMHO, set for 7 September.  I believe we had a great deal of interest in a
BoF, based on the Bar BoF we had at IETF 75.

However, I do believe that consensus indicated that our scope was rather too
broad and should be narrowed substantially.

Here¹s a quick stab at this.  I¹d like a LOT of feedback please, to try to
refine this.  Don¹t take anything included or omitted as any kind of a
statement at all.

Regards
Jason

IETF 76 BoF Proposal
Title: Broadband Home Gateway [HomeGate] BoF
 
Proposed IETF Area: Transport
 
Transport Area Directors:
Lars Eggert ([email-masked])
Magnus Westerlund ([email-masked])
 
BoF Organizers: 
Jason Livingood ([email-masked])
Dave Oran ([email-masked])
 
Conflicts to Avoid:
First Priority: speermint alto ledbat drinks enum v6ops tsvwg dnsext dnsop
Second Priority: behave
BoFs: 
 
Expected Attendance: 25 - 50 people
 
Special Requests: None
 
Number of Sessions: 1
 
Length of Session: 2 hours
  
Proposed Charter:
There are a large number of subscribers to broadband Internet services who
use one form or another of networking technology within the home in order to
share broadband access to the Internet among local users, provide various
LAN services, and provide some basic level of security. The majority of
Internet users employ ³home gateways² for this purpose (they are not purely
³routers²).
 
However, many serious, long-term problems face users of home gateways today.
At the root of many of these problems is the fact that device manufacturers,
and/or the organizations that specify requirements for such devices, are not
certain which IETF standards and best current practices should be supported,
and when/why that support is needed.  As a result of this, millions of
devices are being deployed every year, which do not work with important IETF
protocols, standards, and best practices that are central to the future of
the Internet. 
 
One of the problems in this area appears to be that home gateway vendors are
unclear which RFCs are important, or current, and why they are important and
in what context they matter. Thus, the primary objective of the group is
document a baseline of ³core² RFCs/BCPs which must be supported, followed by
some ³advanced² RFCs/BCPs which are to be considered optional.  The context
and reasoning behind each document which is included should be summarized as
well, in order to improve comprehension of why a given document has been
included.  These things will help improve compatibilities with and
capabilities for use of the Internet of today.  This will include a focus in
areas such as DNS proxy behavior, congestion mechanisms support, and
security. 
 
A secondary problem is compatibility with and capability for the use of the
Internet of tomorrow.  New security needs related to DNS are motivating a
move to DNSSEC.  However, many if not most home gateways cannot handle
DNSSEC, which is expected to be a major problem that could significantly
impede the deployment of DNSSEC globally. Support for IPv6 is also lacking
to a great degree and there is no clear understanding of how such devices
should support IPv6.
 
Proposed Deliverables:
The BoF/WG would work to improve the network experience that a SOHO /
residential home user gets when using the Internet.  This includes providing
a tiered specification for what RFCs and BCPs should be supported, in what
order/priority, and in what manner.  This will touch on standards such as:
o   IPv6

o   DNSSEC RFCs and BCPs

o   ECN

o   RED (or other queue management)

o   DNS Proxy BCPs

o   Security-Related BCPs

o   Other TBD 

Contributors: ISPs and home gateway developers / vendors
 
Proposed Agenda:  (120 minutes)
1  Agenda, Goals, and Administrivia / Chairs
5 minutes
2  HomeGate Problem Statement Exploration
60 minutes
            - Draft problem statement I-D / TBD
10 minutes
            - Issues with DNSSEC, DNS Proxies / Ray Bellis
10 minutes
            - IPv6 support issues / John Brzozowski
10 minutes
            - ECN support issues / TBD
10 minutes
            - Security issues / TBD
10 minutes
            - Zero-Config issues / James Woodyatt?
10 minutes
3  Discussion / All
45 minutes
4  Questions and Next Steps / Chairs
10 minutes

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 01 Sep 2009 17:14:40 -0500

in-line below

At 04:00 PM 9/1/2009, Livingood, Jason wrote:
>So the deadline for BoF requests for the 
>upcoming meeting is rather early IMHO, set for 7 
>September.  I believe we had a great deal of 
>interest in a BoF, based on the Bar BoF we had at IETF 75.
>
>However, I do believe that consensus indicated 
>that our scope was rather too broad and should be narrowed substantially.
>
>Here’s a quick stab at this.  I’d like a LOT of 
>feedback please, to try to refine this.  Don’t 
>take anything included or omitted as any kind of a statement at all.
>
>Regards
>Jason
>
>IETF 76 BoF Proposal
>Lars Eggert (<[email-masked]>[email-masked])
>Magnus Westerlund 
>(<[email-masked]>[email-masked])
>
>BoF Organizers:
>Jason Livingood 
>(<[email-masked]>[email-masked])
>Dave Oran (<[email-masked]>[email-masked])
>
>Conflicts to Avoid:
>There are a large number of subscribers to 
>broadband Internet services who use one form or 
>another of networking technology within the home 
>in order to share broadband access to the 
>Internet among local users, provide various LAN 
>services, and provide some basic level of 
>security. The majority of Internet users employ 
>“home gateways” for this purpose (they are not purely “routers”).

Jason - I suggest an alternate first paragraph 
(as the existing 1st sentence wondered too much IMO), as follows:

"Access to broadband Internet services use 
networking technology of one form or another 
within the home, small office/home office (SOHO) 
or small to medium business (SMB) as the demarc 
between the local network and the Internet. These 
technologies almost always involve a single 
entity - which is not purely a router - called a 
"home gateway".  This entity connects a local 
user or users to various LAN services, providing 
some basic level of security.  The majority of 
Internet users employ home gateways for this purpose."

>
>However, many serious, long-term problems face 
>users of home gateways today.  At the root of 
>many of these problems is the fact that device 
>manufacturers, and/or the organizations that 
>specify requirements for such devices, are not 
>certain which IETF standards and best current 
>practices should be supported, and when/why that 
>support is needed.  As a result of this, 
>millions of devices are being deployed every 
>year, which do not work with important IETF 
>protocols, standards, and best practices that 
>are central to the future of the Internet.
>
>One of the problems in this area appears to be 
>that home gateway vendors are unclear which RFCs 
>are important, or current, and why they are 
>important and in what context they matter. Thus, 
>the primary objective of the group is document a 
>baseline of “core” RFCs/BCPs which must be 
>supported, followed by some “advanced” RFCs/BCPs 
>which are to be considered optional.  The 
>context and reasoning behind each document which 
>is included should be summarized as well, in 
>order to improve comprehension of why a given 
>document has been included.  These things will 
>help improve compatibilities with and 
>capabilities for use of the Internet of 
>today.  This will include a focus in areas such 
>as DNS proxy behavior, congestion mechanisms support, and security.
>
>A secondary problem is compatibility with and 
>capability for the use of the Internet of 
>tomorrow.  New security needs related to DNS are 
>motivating a move to DNSSEC.  However, many if 
>not most home gateways cannot handle DNSSEC, 
>which is expected to be a major problem that 
>could significantly impede the deployment of 
>DNSSEC globally. Support for IPv6 is also 
>lacking to a great degree and there is no clear 
>understanding of how such devices should support IPv6.
>
>Proposed Deliverables:
>The BoF/WG would work to improve the network 
>experience that a SOHO / residential home user 
>gets when using the Internet.  This includes 
>providing a tiered specification for what RFCs 
>and BCPs should be supported, in what 
>1 – Agenda, Goals, and Administrivia / 
>Chairs                                                5 minutes
>2 – HomeGate Problem Statement 
>Exploration                                               60 minutes
>             - Draft problem statement I-D / 
> TBD                                                         10 minutes
>             - Issues with DNSSEC, DNS Proxies / 
> Ray Bellis                                      10 minutes
>             - IPv6 support issues / John 
> Brzozowski                                                    10 minutes
>             - ECN support issues / 
> TBD 
> 10 minutes
>             - Security issues / 
> TBD 
> 10 minutes
>             - Zero-Config issues / James 
> Woodyatt?                                                   10 minutes
>3 – Discussion / 
>All 
>45 minutes
>4 – Questions and Next Steps / 
>Chairs                                                            10 minutes
>
>_______________________________________________
>homegate mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homegate

---

From: ken carlberg <[email-masked]>
Date: Tue, 1 Sep 2009 20:58:35 -0400

On Sep 1, 2009, at 5:00 PM, Livingood, Jason wrote:

> Proposed Deliverables:
> The BoF/WG would work to improve the network experience that a  
> SOHO / residential home user gets when using the Internet.  This  
> includes providing a tiered specification for what RFCs and BCPs  
> should be supported, in what order/priority, and in what manner.   
> This will touch on standards such as:

> o   RED (or other queue management)

could you expand on what is meant by "will touch on standards"?

One thing I thought that the participants in the BoF seemed to  
gravitate to was a simple requirements doc like what was produced ages  
ago in rfc-1812 and rfc-1123.  If this is what you meant in the above  
excerpt, then its probably best to say so more explicitly.  And while  
I appreciate interest expressed in the BoF for a more in-depth  
requirements document covering areas like VPNs, I'd prefer to keep  
that separate and sequential to a baseline requirements doc.

-ken

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Sep 2009 19:00:46 -0700

At 8:58 PM -0400 9/1/09, ken carlberg wrote:

On Sep 1, 2009, at 5:00 PM, Livingood,
Jason wrote:

Proposed Deliverables:

residential home user gets when using the Internet.  This

o
IPv6

o   DNSSEC RFCs and BCPs

o   ECN

o   DNS Proxy BCPs

o   Security-Related BCPs

o   Other TBD

could you expand on what is meant by
"will touch on standards"?

One thing I thought that the participants
in the BoF seemed to gravitate to was a simple requirements doc like
what was produced ages ago in rfc-1812 and rfc-1123.  If this is
what you meant in the above excerpt, then its probably best to say so
more explicitly.  And while I appreciate interest expressed in
the BoF for a more in-depth requirements document covering areas like
VPNs, I'd prefer to keep that separate and sequential to a baseline
requirements doc.

Another way to factor the work would be a base document that
*only* covered IPv4, IPv6, and DNS (including DNSSEC). Additional
topic-specific docs could be added if there was agreement in the WG. I
would not want to mention "DNS proxies BCPs" in the main
doc: SOHO boxes really should rely on ISPs for DNS.
"Security-related BCP" probably means "documenting
stupid firewall tricks", and those may be hard to come to
consensus on.

Thus, I would change the latter part of the BoF proposal
to:

Proposed Deliverables:

The eventual WG's goal is to improve the network experience that
a SOHO / residential home user gets when using the Internet. To do
this, the WG will create one or more BCP-style documents aimed at home
gateway vendors pointing to the RFCs that they should support, and
pointing out specific areas where there are known problems today due
to not including important features or mis-implementation of important
features.

The first document to be produced by the WG would cover IPv4,
IPv6, and DNS (including DNSSEC) and little else. The WG can add
follow-on documents to the charter later after showing enough interest
to write and review those documents. These additional documents might
cover topics such as firewall best practices, ECN, RED, DNS proxies,
and so on.

(As a side note, charters are plain-text, even in 2009.)

--Paul Hoffman, Director

--VPN Consortium

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 01 Sep 2009 22:36:02 -0500

At 09:00 PM 9/1/2009, Paul Hoffman wrote:
>>>should be supported, in what order/priority, and in what 
>>>manner.  This will touch on standards such as:
>>
>>>o   IPv6
>>>
>>>o   DNSSEC RFCs and BCPs
>>>
>>>o   ECN
>>>
>>gravitate to was a simple requirements doc like what was produced 
>>ages ago in rfc-1812 and rfc-1123.  If this is what you meant in 
>>the above excerpt, then its probably best to say so more 
>>explicitly.  And while I appreciate interest expressed in the BoF 
>>for a more in-depth requirements document covering areas like VPNs, 
>>I'd prefer to keep that separate and sequential to a baseline requirements doc.
>
>Another way to factor the work would be a base document that *only* 
>covered IPv4, IPv6, and DNS (including DNSSEC). Additional 
>topic-specific docs could be added if there was agreement in the WG. 
>I would not want to mention "DNS proxies BCPs" in the main doc: SOHO 
>boxes really should rely on ISPs for DNS. "Security-related BCP" 
>probably means "documenting stupid firewall tricks", and those may 
>be hard to come to consensus on.
>
>Thus, I would change the latter part of the BoF proposal to:
>
>Proposed Deliverables:
>
>The eventual WG's goal is to improve the network experience that a 
>SOHO / residential home user gets when using the Internet. To do 
>this, the WG will create one or more BCP-style documents aimed at 
>home gateway vendors pointing to the RFCs that they should support, 
>and pointing out specific areas where there are known problems today 
>due to not including important features or mis-implementation of 
>important features.
>
>The first document to be produced by the WG would cover IPv4, IPv6, 
>and DNS (including DNSSEC) and little else. The WG can add follow-on 
>documents to the charter later after showing enough interest to 
>write and review those documents. These additional documents might 
>cover topics such as firewall best practices, ECN, RED, DNS proxies, and so on.

While I'm not sold on the idea of v4, v6 and DNS *only* in the first 
doc (I think firewall best practices should be in here, as well as 
what not to break that is already standardized (i.e., ECN)), I firmly 
believe the charter should state that this group will *not* produce 
standards track documents, as that is left for the specific WGs that 
are chartered to work on those protocols in the standards track 
effort. I think this needs to be explicit in the charter. BCPs should 
be the strongest status of doc from this group.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Sep 2009 09:11:55 -0700

At 10:36 PM -0500 9/1/09, James M. Polk wrote:
>While I'm not sold on the idea of v4, v6 and DNS *only* in the first doc (I think firewall best practices should be in here, as well as what not to break that is already standardized (i.e., ECN)),

Let's tease those two things out a bit. I believe both are way more controversial than you would hope.

Firewall best practices are mostly about allowing users to block/allow certain ports and applications. Ports are easy, applications are difficult. There is a *huge* difference between port filtering and  application sniffing. Without application sniffing, the actual security offered is much worse. So, for home and SOHO routers, do we say "here's how to offer worse security" or "you need to offer good security, which is much more than most of the devices do today"? I propose that there will strong opinions on both sides.

"Do not break standardized things" sounds good, but the question is whether it is easy. That is, how much packet inspection and follow-up processing is needed to not break each feature? And what is our list of features? ECN seems obvious, but it is barely seen in the wild due to chicken-and-egg problems. Would SIP be on that list? IKE? IKEv2?

> I firmly believe the charter should state that this group will *not* produce standards track documents, as that is left for the specific WGs that are chartered to work on those protocols in the standards track effort. I think this needs to be explicit in the charter. BCPs should be the strongest status of doc from this group.

This is a common misconception. BCPs *are* essentially standards track documents; see RFC 2026. You probably meant that the WG would not produce documents introduce new protocols or change existing protocols. On that, I think there is widespread agreement.

--Paul Hoffman, Director
--VPN Consortium

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 02 Sep 2009 12:35:22 -0500

At 11:11 AM 9/2/2009, Paul Hoffman wrote:
> >While I'm not sold on the idea of v4, v6 and DNS *only* in the 
> first doc (I think firewall best practices should be in here, as 
> well as what not to break that is already standardized (i.e., ECN)),
>
>Firewall best practices are mostly about allowing users to 
>block/allow certain ports and applications. Ports are easy, 
>applications are difficult. There is a *huge* difference between 
>port filtering and  application sniffing. Without application 
>sniffing, the actual security offered is much worse. So, for home 
>and SOHO routers, do we say "here's how to offer worse security" or 
>"you need to offer good security, which is much more than most of 
>the devices do today"? I propose that there will strong opinions on both sides.

I don't understand why this group doesn't do the latter of your two 
quotes. "...which is much more than most of the devices do today..." 
is what Homegate is all about, isn't it? I mean, look at the proposed 
charter and tell me where this mindset is inconsistent...?

>"Do not break standardized things" sounds good, but the question is 
>whether it is easy. That is, how much packet inspection and 
>follow-up processing is needed to not break each feature? And what 
>is our list of features? ECN seems obvious, but it is barely seen in 
>the wild due to chicken-and-egg problems. Would SIP be on that list? 
>IKE? IKEv2?

This is exactly what I believe the group ought to discuss, and not 
decide day -50 of the WG forming.  I agree with the minimum goal of 
starting with v4, v6 and DNS -- but adding to the list as the group 
thinks it can accomplish the next protocol or function to be 
specified, then the next, then the next, to the point that the group 
believes "now we have a critical mass of minimum *things* included, 
we'll run with this list in our first doc".

You're right, ECN seems obvious. I don't know what is the next one 
is, or the one after that. I know I have my list of preferences, and 
I believe I have to justify each one to this group to gain agreement 
that each should be included (right?).

> > I firmly believe the charter should state that this group will 
> *not* produce standards track documents, as that is left for the 
> specific WGs that are chartered to work on those protocols in the 
> standards track effort. I think this needs to be explicit in the 
> charter. BCPs should be the strongest status of doc from this group.
>
>This is a common misconception.

you misunderstand...

>BCPs *are* essentially standards track documents; see RFC 2026.

I've always believed BCPs are "one shot" standards, and not 
"standards track" (the latter meaning there are more than one 
standards level within the "track" - such as PS, DS and FS).

This differentiation has always been clear in all the WGs I've 
written IDs into (I think 11 so far), as well as TSVWG that I chair.

>You probably meant that the WG would not produce documents introduce 
>new protocols or change existing protocols.

not producing any PS, DS or FS RFC, yes - this group should not.

>On that, I think there is widespread agreement.

but I don't see that in the charter, and it would greatly help 
prevent the future wonderer - who might be new to the group with 
legitimate intentions of contributing their energy that might not see 
this in the current charter text that would greatly benefit if it were there.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Sep 2009 16:41:45 -0700

At 12:35 PM -0500 9/2/09, James M. Polk wrote:
>I don't understand why this group doesn't do the latter of your two quotes. "...which is much more than most of the devices do today..." is what Homegate is all about, isn't it? I mean, look at the proposed charter and tell me where this mindset is inconsistent...?

Three likely reasons:

- Application sniffing is much more CPU-intensive than port blocking

- It also takes much more expensive programming for these cheap devices

- Getting rough consensus in an IETF WG about how to block application protocols could be really really hard

>This is exactly what I believe the group ought to discuss, and not decide day -50 of the WG forming.  I agree with the minimum goal of starting with v4, v6 and DNS -- but adding to the list as the group thinks it can accomplish the next protocol or function to be specified, then the next, then the next, to the point that the group believes "now we have a critical mass of minimum *things* included, we'll run with this list in our first doc".

OK, maybe I was being too cautious. If we can get an early list of standardized things that we are willing to work on at the BoF, there is no reason not to put them in the initial WG charter.

>You're right, ECN seems obvious. I don't know what is the next one is, or the one after that. I know I have my list of preferences, and I believe I have to justify each one to this group to gain agreement that each should be included (right?).

Right, we could do a laundry list request, not for discussion immediately, but to find if there is enough juiced to work on them.

>but I don't see that in the charter, and it would greatly help prevent the future wonderer - who might be new to the group with legitimate intentions of contributing their energy that might not see this in the current charter text that would greatly benefit if it were there.

Ah, good point. I would definitely support putting that in the charter.

--Paul Hoffman, Director
--VPN Consortium

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 03 Sep 2009 01:40:01 -0500

At 06:41 PM 9/2/2009, Paul Hoffman wrote:
> >>"Do not break standardized things" sounds good, but the question 
> is whether it is easy. That is, how much packet inspection and 
> is our list of features? ECN seems obvious, but it is barely seen 
> in the wild due to chicken-and-egg problems. Would SIP be on that 
> list? IKE? IKEv2?
> >
> specified, then the next, then the next, to the point that the 
> group believes "now we have a critical mass of minimum *things* 
> included, we'll run with this list in our first doc".
>
>OK, maybe I was being too cautious. If we can get an early list of 
>standardized things that we are willing to work on at the BoF, there 
>is no reason not to put them in the initial WG charter.
>
> is, or the one after that. I know I have my list of preferences, 
> and I believe I have to justify each one to this group to gain 
> agreement that each should be included (right?).
>
>Right, we could do a laundry list request, not for discussion 
>immediately, but to find if there is enough juiced to work on them.
>
> legitimate intentions of contributing their energy that might not 
> see this in the current charter text that would greatly benefit if 
> it were there.
>

cool, at least we two agree.

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 03 Sep 2009 11:15:35 -0400

Excellent improvement, incorporated into my latest version (sending soon)!

On 9/1/09 6:14 PM, "James M. Polk" <[email-masked]> wrote:

>> Here¹s a quick stab at this.  I¹d like a LOT of
>> feedback please, to try to refine this.  Don¹t
>> ³home gateways² for this purpose (they are not purely ³routers²).
> 
>> baseline of ³core² RFCs/BCPs which must be
>> supported, followed by some ³advanced² RFCs/BCPs
>> 1  Agenda, Goals, and Administrivia /
>> Chairs                                                5 minutes
>> 2  HomeGate Problem Statement
>> Exploration                                               60 minutes
>> 3  Discussion /
>> 4  Questions and Next Steps /
>> Chairs                                                            10 minutes
>> 

Regards,
Jason
 
Jason Livingood
Executive Director
Internet Systems Engineering
National Engineering & Technical Operations
Comcast Cable Communications
215-286-7813
[email-masked]

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 03 Sep 2009 11:20:54 -0400

I understand Paul's desire to constrain the problem space.  But I tend to
agree with James that IPv4 and v6 and DNS may not be enough.  Here's a
proposed addition to the charter to try to make it clear that new protocol
work is not the aim:

"This working group will not develop new or extend existing Internet
protocols.  Should any such need develop, the chairs will refer the work to
another working group that is chartered to focus on the relevant problem."

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 03 Sep 2009 11:23:57 -0400

> This is a common misconception. BCPs *are* essentially standards track
> documents; see RFC 2026. You probably meant that the WG would not produce
> documents introduce new protocols or change existing protocols. On that, I
> think there is widespread agreement.

Precisely why I didn't say "standards track" in this below.  The important
thing is to steer clear of things like developing protocols. That is much
better left to other WGs.

JL

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 03 Sep 2009 11:29:42 -0400

Here is the latest version.  Feedback welcome, as always.  Take a look at
the priorities as well.  I have coded the changes in BLUE.

Proposed Charter:
Access to broadband Internet services use networking technology of one form
or another 
within the home, small office/home office (SOHO) or small to medium business
(SMB) as the demarcation between the local network and the Internet. These
technologies almost always involve a single entity - which is not purely a
router - called a "home gateway".  This entity connects a local user or
users to various LAN services, providing some basic level of security.  The
majority of Internet users employ home gateways for this purpose.

 
 
This working group will not develop new or extend existing Internet
protocols.  Should any such need develop, the chairs will refer the work to
another working group that is chartered to focus on the relevant problem.
 
Proposed Deliverables and Priorities:

o   DNSSEC RFCs and BCPs

o   ECN

o   DNS Proxy BCPs

o   Security-Related BCPs

o   Other TBD

The group shall prioritize work as follows:
1.    IPv4-related topics

2.    IPv6-related topics

3.    DNS-related topics (DNSSEC, DNS Proxies, etc.)

4.    ECN-related topics (congestion and queue management)

5.    Security-related topics

---

From: <[email-masked]>
Date: Thu, 3 Sep 2009 12:13:16 -0400

I would recommend striking the phrase or small to medium business (SMB) from the proposed charter. Extending beyond the SOHO to the the SMB drastically increases the number of possible network topologies. This seems to imply that you are no longer interested in just the home network architecture but all small office park/building and similar networks as well. If this is the intent then the term homegate and the stated deliverables may be a tad too narrow in scope.

Jason Weil

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Livingood, Jason
Sent: Thursday, September 03, 2009 11:30 AM
To: [email-masked]
Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope!

Here is the latest version.  Feedback welcome, as always.  Take a look at the priorities as well.  I have coded the changes in BLUE.

Proposed Charter:
Access to broadband Internet services use networking technology of one form or another
within the home, small office/home office (SOHO) or small to medium business (SMB) as the demarcation between the local network and the Internet. These technologies almost always involve a single entity - which is not purely a router - called a "home gateway".  This entity connects a local user or users to various LAN services, providing some basic level of security.  The majority of Internet users employ home gateways for this purpose.

However, many serious, long-term problems face users of home gateways today.  At the root of many of these problems is the fact that device manufacturers, and/or the organizations that specify requirements for such devices, are not certain which IETF standards and best current practices should be supported, and when/why that support is needed.  As a result of this, millions of devices are being deployed every year, which do not work with important IETF protocols, standards, and best practices that are central to the future of the Internet.

One of the problems in this area appears to be that home gateway vendors are unclear which RFCs are important, or current, and why they are important and in what context they matter. Thus, the primary objective of the group is document a baseline of "core" RFCs/BCPs which must be supported, followed by some "advanced" RFCs/BCPs which are to be considered optional.  The context and reasoning behind each document which is included should be summarized as well, in order to improve comprehension of why a given document has been included.  These things will help improve compatibilities with and capabilities for use of the Internet of today.  This will include a focus in areas such as DNS proxy behavior, congestion mechanisms support, and security.

A secondary problem is compatibility with and capability for the use of the Internet of tomorrow.  New security needs related to DNS are motivating a move to DNSSEC.  However, many if not most home gateways cannot handle DNSSEC, which is expected to be a major problem that could significantly impede the deployment of DNSSEC globally. Support for IPv6 is also lacking to a great degree and there is no clear understanding of how such devices should support IPv6.

This working group will not develop new or extend existing Internet protocols.  Should any such need develop, the chairs will refer the work to another working group that is chartered to focus on the relevant problem.

Proposed Deliverables and Priorities:
The BoF/WG would work to improve the network experience that a SOHO / residential home user gets when using the Internet.  This includes providing a tiered specification for what RFCs and BCPs should be supported, in what order/priority, and in what manner. This will touch on standards such as:
o   IPv6

o   DNSSEC RFCs and BCPs

o   ECN

o   DNS Proxy BCPs

o   Security-Related BCPs

o   Other TBD

2.    IPv6-related topics

On 9/1/09 5:00 PM, "Jason Livingood" <[email-masked]> wrote:

So the deadline for BoF requests for the upcoming meeting is rather early IMHO, set for 7 September.  I believe we had a great deal of interest in a BoF, based on the Bar BoF we had at IETF 75.

However, I do believe that consensus indicated that our scope was rather too broad and should be narrowed substantially.

Here's a quick stab at this.  I'd like a LOT of feedback please, to try to refine this.  Don't take anything included or omitted as any kind of a statement at all.

Regards
Jason

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 3 Sep 2009 15:34:35 -0400

I have 2 concerns:

1.       IPv6 - v6ops is currently working on a draft identifying which
IPv6 RFCs "CPE Routers" (which is pretty much the same thing as a home
gateway, in my book) need to support. Homegate's claim of ownership over
this topic is in direct conflict. I believe these IPv6 recommendations
are quite important (just like the proposed charter says); so important
that I don't want to see in-fighting over ownership, transfer of
ownership, or anything that might derail or slow down progress. v6ops
has an aggressive schedule in mind for these requirements. I do not see
how homegate inserting itself into the equation will have anything but a
negative impact on the continuity of work and timelines.

2.       DNSSEC - I am not convinced that DNSSEC deployment is critical
for the future. I am willing to discuss and consider it with an open
mind; but only within the context of WG list discussions, and not within
the context of the proposed charter of a WG. If the WG charter included
identification of best practices, present and future, around DNS
(looking at DNS Proxy, DNSSEC, Dynamic DNS, in-home domain, etc.), then
I think that might be a good thing, and there could be good discussion.
I disagree with having the charter state that it's a given that DNSSEC
is a must have for the future and that the only question is how to
convince home gateway vendors to implement it.

Barbara

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Livingood, Jason
Sent: Thursday, September 03, 2009 11:30 AM
To: [email-masked]
Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow
our scope!

Here is the latest version.  Feedback welcome, as always.  Take a look
at the priorities as well.  I have coded the changes in BLUE.

Proposed Charter:
Access to broadband Internet services use networking technology of one
form or another 
within the home, small office/home office (SOHO) or small to medium
business (SMB) as the demarcation between the local network and the
Internet. These technologies almost always involve a single entity -
which is not purely a router - called a "home gateway".  This entity
connects a local user or users to various LAN services, providing some
basic level of security.  The majority of Internet users employ home
gateways for this purpose.

However, many serious, long-term problems face users of home gateways
today.  At the root of many of these problems is the fact that device
manufacturers, and/or the organizations that specify requirements for
such devices, are not certain which IETF standards and best current
practices should be supported, and when/why that support is needed.  As
a result of this, millions of devices are being deployed every year,
which do not work with important IETF protocols, standards, and best
practices that are central to the future of the Internet. 

One of the problems in this area appears to be that home gateway vendors
are unclear which RFCs are important, or current, and why they are
important and in what context they matter. Thus, the primary objective
of the group is document a baseline of "core" RFCs/BCPs which must be
supported, followed by some "advanced" RFCs/BCPs which are to be
considered optional.  The context and reasoning behind each document
which is included should be summarized as well, in order to improve
comprehension of why a given document has been included.  These things
will help improve compatibilities with and capabilities for use of the
Internet of today.  This will include a focus in areas such as DNS proxy
behavior, congestion mechanisms support, and security. 
 
A secondary problem is compatibility with and capability for the use of
the Internet of tomorrow.  New security needs related to DNS are
motivating a move to DNSSEC.  However, many if not most home gateways
cannot handle DNSSEC, which is expected to be a major problem that could
significantly impede the deployment of DNSSEC globally. Support for IPv6
is also lacking to a great degree and there is no clear understanding of
how such devices should support IPv6.
 
This working group will not develop new or extend existing Internet
protocols.  Should any such need develop, the chairs will refer the work
to another working group that is chartered to focus on the relevant
problem.

Proposed Deliverables and Priorities:
The BoF/WG would work to improve the network experience that a SOHO /
residential home user gets when using the Internet.  This includes
providing a tiered specification for what RFCs and BCPs should be
supported, in what order/priority, and in what manner. This will touch
on standards such as:
o   IPv6

o   DNSSEC RFCs and BCPs

o   ECN

o   DNS Proxy BCPs

o   Security-Related BCPs

o   Other TBD

2.    IPv6-related topics

So the deadline for BoF requests for the upcoming meeting is rather
early IMHO, set for 7 September.  I believe we had a great deal of
interest in a BoF, based on the Bar BoF we had at IETF 75.  

However, I do believe that consensus indicated that our scope was rather
too broad and should be narrowed substantially.

Here's a quick stab at this.  I'd like a LOT of feedback please, to try
to refine this.  Don't take anything included or omitted as any kind of
a statement at all.

Regards
Jason

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 03 Sep 2009 14:48:35 -0500

>another working group that is chartered to focus on the relevant problem."

I like this new text.

James

> >> cover topics such as firewall best practices, ECN, RED, DNS 
> proxies, and so
> >> on.
> >

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 03 Sep 2009 14:59:37 -0500

At 11:13 AM 9/3/2009, [email-masked] wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
> 
>boundary="_000_C1920346B731FE48822877D74F28C8A307A2D15C59CATL0MS112cor_"
>
>I would recommend striking the phrase or small to medium business 
>(SMB) from the proposed charter. Extending beyond the SOHO to the 
>the SMB drastically increases the number of possible network topologies.

yeah - but we're talking about defining the demarcation entity only. 
We're not choosing between token ring (which might be in a SMB) and 
Ethernet (which will nearly always be in the home) as a consideration.

"SMB" is the market segment name, and while I'm not a fan of covering 
a 300-400 user medium business, we certainly want to cover a 
Starbucks, or a small insurance company, or a bank branch office, or 
a McDonalds type of location.  This is certainly within the same 
scope as a power home user that has 50-100 Cat 5 jacks in their home 
(with 10-20+ being active).  It's the same scale, and we're talking 
about the same network entity demarc.

Each of the SMB instances I gave above certainly are the target of an 
MSO or business class DSL offering. Admittedly this is on the upper 
end of what this group should touch.

James

>This seems to imply that you are no longer interested in just the 
>home network architecture but all small office park/building and 
>similar networks as well. If this is the intent then the term 
>homegate and the stated deliverables may be a tad too narrow in scope.
>
>Jason Weil
>
>
>----------
>Here is the latest version.  Feedback welcome, as always.  Take a 
>look at the priorities as well.  I have coded the changes in BLUE.
>
>Proposed Charter:
>connects a local user or users to various LAN services, providing 
>some basic level of security.  The majority of Internet users employ 
>home gateways for this purpose.
>
>However, many serious, long-term problems face users of home 
>gateways today.  At the root of many of these problems is the fact 
>that device manufacturers, and/or the organizations that specify 
>requirements for such devices, are not certain which IETF standards 
>and best current practices should be supported, and when/why that 
>support is needed.  As a result of this, millions of devices are 
>being deployed every year, which do not work with important IETF 
>protocols, standards, and best practices that are central to the 
>future of the Internet.
>
>One of the problems in this area appears to be that home gateway 
>vendors are unclear which RFCs are important, or current, and why 
>they are important and in what context they matter. Thus, the 
>primary objective of the group is document a baseline of "core" 
>RFCs/BCPs which must be supported, followed by some "advanced" 
>RFCs/BCPs which are to be considered optional.  The context and 
>reasoning behind each document which is included should be 
>summarized as well, in order to improve comprehension of why a given 
>document has been included.  These things will help improve 
>compatibilities with and capabilities for use of the Internet of 
>today.  This will include a focus in areas such as DNS proxy 
>A secondary problem is compatibility with and capability for the use 
>of the Internet of tomorrow.  New security needs related to DNS are 
>motivating a move to DNSSEC.  However, many if not most home 
>gateways cannot handle DNSSEC, which is expected to be a major 
>problem that could significantly impede the deployment of DNSSEC 
>globally. Support for IPv6 is also lacking to a great degree and 
>there is no clear understanding of how such devices should support IPv6.
>
>protocols.  Should any such need develop, the chairs will refer the 
>work to another working group that is chartered to focus on the 
>relevant problem.
>
>The BoF/WG would work to improve the network experience that a SOHO 
>/ residential home user gets when using the Internet.  This includes 
>supported, in what order/priority, and in what manner. This will 
>touch on standards such as:
>o   IPv6
>
>o   DNSSEC RFCs and BCPs
>
>o   ECN
>
>On 9/1/09 5:00 PM, "Jason Livingood" 
><<[email-masked]>[email-masked]> wrote:
>
>However, I do believe that consensus indicated that our scope was 
>rather too broad and should be narrowed substantially.
>
>Here's a quick stab at this.  I'd like a LOT of feedback please, to 
>try to refine this.  Don't take anything included or omitted as any 
>kind of a statement at all.
>
>Regards
>Jason
>

---

From: [email-masked]
Date: Fri, 4 Sep 2009 10:25:01 +0100

> 2.       DNSSEC – I am not convinced that DNSSEC deployment is 
> critical for the future. I am willing to discuss and consider it 
> with an open mind; but only within the context of WG list 
> discussions, and not within the context of the proposed charter of a
> WG. If the WG charter included identification of best practices, 
> present and future, around DNS (looking at DNS Proxy, DNSSEC, 
> Dynamic DNS, in-home domain, etc.), then I think that might be a 
> good thing, and there could be good discussion. I disagree with 
> having the charter state that it’s a given that DNSSEC is a must 
> have for the future and that the only question is how to convince 
> home gateway vendors to implement it.

I strongly diagree.

DNSSEC _is_ coming, but home gateways can and do interfere with its 
correct operation.

Fortunately much of this is already covered by my RFC 5625.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 4 Sep 2009 10:09:50 -0400

And I have no problem with the things I read in RFC 5625. But I read those as “the home gateway must not interfere with DNSSEC”, and not “the home gateway must support DNSSEC”. There’s a difference between non-interference and support. I didn’t see in the RFC where the gateway needed to actually know that DNSSEC was happening, and react accordingly. If I missed that part, please let me know.

Barbara

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, September 04, 2009 5:25 AM
To: Stark, Barbara
Cc: [email-masked]; [email-masked]; Livingood, Jason
Subject: Re: [homegate] Homegate BoF @ IETF 76? Then we need to narrow our scope!

I strongly diagree. 

DNSSEC _is_ coming, but home gateways can and do interfere with its correct operation. 

Ray

---

From: [email-masked]
Date: Fri, 4 Sep 2009 15:21:39 +0100

> And I have no problem with the things I read in RFC 5625. But I read
> those as “the home gateway must not interfere with DNSSEC”, and not 
> “the home gateway must support DNSSEC”. There’s a difference between
> non-interference and support. I didn’t see in the RFC where the 
> gateway needed to actually know that DNSSEC was happening, and react
> accordingly. If I missed that part, please let me know.

Ah, in that case I see what you mean.

Indeed I would rather that the proxy got out of the way if at all 
possible, and I would also agree that home gateways _shouldn't_ actively 
participate in DNSSEC at all.

The right place (IMHO) for DNSSEC is on the client stub, or possibly at 
the ISP's recursor.  It shouldn't be on some middlebox sat in the middle.

Ray

---

From: Ralph Droms <[email-masked]>
Date: Fri, 4 Sep 2009 11:04:10 -0400

I agree that current home gateways interfere needlessly with DNS.

However, in future deployments esp. including IPv6, uninterrupted DNS  
service in the home may be important.  Similarly, DNSSEC for hosts in  
the home that don't have a DNSSEC stub client will be important.  So,  
I see a full DNSSEC-capable recursive resolver in the home gateway as  
an alternative to be considered.

- Ralph

On Sep 4, 2009, at 10:21 AM 9/4/09, [email-masked] wrote:

> possible, and I would also agree that home gateways _shouldn't_  
> actively participate in DNSSEC at all.
>
> The right place (IMHO) for DNSSEC is on the client stub, or possibly  
> at the ISP's recursor.  It shouldn't be on some middlebox sat in the  
> middle.
>
> Ray

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 04 Sep 2009 13:14:37 -0400

And, as such, we may simply find we can address this as noted below, but
with somewhat more text.

Jason

On 9/4/09 10:21 AM, "Ray Bellis" <[email-masked]> wrote:

>> > those as ³the home gateway must not interfere with DNSSEC², and not
>> > ³the home gateway must support DNSSEC². There¹s a difference between
>> > non-interference and support. I didn¹t see in the RFC where the
> Indeed I would rather that the proxy got out of the way if at all possible,
> and I would also agree that home gateways _shouldn't_ actively participate in
> DNSSEC at all. 
> 
> The right place (IMHO) for DNSSEC is on the client stub, or possibly at the
> ISP's recursor.  It shouldn't be on some middlebox sat in the middle.
> 
Ray

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 04 Sep 2009 13:17:22 -0400

Re IPv6-related issues, we¹re certainly aware of the work v6ops is doing on
CPE routers.  We may end up referring to what they are doing, or we may have
a different take on it since we may be describing how v4 and v6 should work
in the same device (which again may overlap).  In such case, we¹ll seek the
guidance of the relevant ADs, since that¹s part of what they¹re here for.

Jason

On 9/3/09 3:34 PM, "Stark, Barbara" <[email-masked]> wrote:

> I have 2 concerns:
> 1.      IPv6  v6ops is currently working on a draft identifying which IPv6
> RFCs ³CPE Routers² (which is pretty much the same thing as a home gateway, in
> my book) need to support. Homegate¹s claim of ownership over this topic is in
> direct conflict. I believe these IPv6 recommendations are quite important
> (just like the proposed charter says); so important that I don¹t want to see
> in-fighting over ownership, transfer of ownership, or anything that might
> derail or slow down progress. v6ops has an aggressive schedule in mind for
> these requirements. I do not see how homegate inserting itself into the
> equation will have anything but a negative impact on the continuity of work
> and timelines.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Sep 2009 17:32:46 -0400

> the ISP's recursor.  It shouldn't be on some middlebox sat in the middle.

Well, anyway, it _needn't_ be on some clueless middlebox.

I can think of a really nice deployment scenario in which the gateway
does all validation, and in fact mostly replaces some of the work that
would otherwise be done by the central ISP's name servers.  In
particular, if I were an ISP, I could see great gains to be had by
adding $5 to the initial acquisition cost of a customer, who would
then get a more intelligent validating box, just so that I wouldn't
have to spend $BIGNUM on centralised validating resolvers.  This for
two reasons:

1.  Centralized validators could be a fairly serious CPU hog, which
effectively means much more money sunk into that service to make sure
it is adequately provisioned.

2.  Distributing the workload also means that a peculiar,
locally-generated high load query (or series thereof) does not cause
everyone's validation to slow down.

Better still, I could charge extra for the "secure DNS" service for
the first few years its rolling out -- premium service gets a premium
box.  If the end node so happens to do all its own validation as well,
bully for it.  But in the meantime, there's a validator out near the
edge, where it is still potentially effective, unlikely to be on-path
attacked (stub to validator), and not shared by every user.

All of this is especially true when we think of this as SOHO-gate, as
(I think it was) Paul Hoffman urged when we were in Stockholm.

None of this is to say we ought to be mandating any of the above, but
I see no harm in describing this use profile as part of the homegate
work.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Baugher <[email-masked]>
Date: Fri, 4 Sep 2009 14:38:28 -0700

On 4/09/2009, at 8:04 AM, Ralph Droms wrote:

> However, in future deployments esp. including IPv6, uninterrupted  
> DNS service in the home may be important.

Uninterrupted DNS service is certainly important, but so is  
uninterrupted Internet service.  So we already depend on the SP for  
broadband service.  Why not depend on them for DNS as well?

Pushing lots of function into an unmanaged device is ill-advised.  And  
we are talking about an unmanaged device, for the most part.

My two cents.

Mark

> Similarly, DNSSEC for hosts in the home that don't have a DNSSEC  
> stub client will be important.  So, I see a full DNSSEC-capable  
> recursive resolver in the home gateway as an alternative to be  
> considered.
>
> - Ralph
>
>> The right place (IMHO) for DNSSEC is on the client stub, or  
>> possibly at the ISP's recursor.  It shouldn't be on some middlebox  
>> sat in the middle.
>>
>> Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Sep 2009 18:28:57 -0400

> broadband service.  Why not depend on them for DNS as well?

Speaking as a disgruntled consumer, it's because many of them have a
countervailing interest to implementing DNSSEC[1].  I don't want to
imagine for a moment that we can specify away people's nasty and
mercenary business practices, but I do think it worthwhile to specify
an interoperable way for non-mercenary ISPs to distinguish themselves
consistently.

A

[1] For those not aware, several large ISPs do nasty things to DNS
query answers in an effort to "protect" their customers.  This
protection quite often involves the redirection of various kinds of
answers to a "landing" host, which host actually only speaks HTTP,
meaning that "internet service provision" boils down to "web service
provision".  It turns out that there's a small but not ignored revenue
stream available from this sort of redirection.  Therefore, some ISPs
are opposed "in principle" to pushing DNS resolution out to the end
node.  I am aware that there's an argument stemming from certain
malware that this attempt to control DNS traffic is still warranted.
I find it hard to swallow such a claim if there's no opt-out function
at all.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 6 Sep 2009 14:54:52 +0200

> have to spend $BIGNUM on centralised validating resolvers.  This for

I'm not disagreeing with any of this, but I am very worried about what  
will happen when there is a snag somewhere. I currently have a CPE  
that is mostly managed by my ISP, and it says that it is the DNS  
server in DHCP. I don't know what forwarders it uses, but I do know  
they're pretty crappy from time to time, triggering me to switch to  
OpenDNS. The problem with that is that I can't have the CPE  
automatically advertise the OpenDNS addresses to my hosts so I need to  
set it up manually, forget that it's there so I still use OpenDNS at  
work etc etc.

Now imagine what can go wrong with DNSSEC validation. First of all,  
this is all quite new so prone to be buggy. Then, when OSes start to  
support it, the resolver libraries will start asking stuff from the  
integrated DNSSEC implementations that they didn't ask before,  
providing an opportunity to be bitten by previously unseen bugs. How  
are the trust anchors managed? What if there is a breakdown in the  
trust delegation somewhere, making it necessary to turn DNSSEC off,  
possibly for only part of the naming hierarchy?

Do we really want something this complex and relatively unproven in an  
unmanaged or at best bulk-managed device?

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 06 Sep 2009 15:41:16 -0400

> we are talking about an unmanaged device, for the most part.

Yes, particularly when the local security of some of those devices is
relatively poor (such as when many users leave the default admin p/w in
place for the life of the device).

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 06 Sep 2009 15:46:05 -0400

For background, I believe Andrew primarily refers to a recent draft that's
been discussed in DNSOP, so please wander over there for more discussion and
take a look as well at
http://tools.ietf.org/html/draft-livingood-dns-redirect-00 (to be updated in
the next 30 - 45 days).

Jason

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Sep 2009 10:29:15 -0400

> unmanaged or at best bulk-managed device?

Surely all of those considerations are exactly what we should be
documenting, and for which we need to state the trade-offs?  I'm not
arguing that we should be mandating anything in this area, but it
doesn't seem silly to say, "If you're going to do _X_, this is how to
do it."  That would doubtless include pointers to root trust anchor
management, to security practices that ensure the device isn't a major
vector for problems, &c. &c.  

If that's not the sort of work we're talking about undertaking, then
I've probably misunderstood exactly what it is we were supposed to be
planning to do.  As others have pointed out, there are already SDOs
specifying various pieces in this area, and I don't see any reason to
reproduce that other work.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.