Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC

> On Nov 18, 2013, at 2:42 AM, Marc Lampo <marc.lampo.ietf@gmail.com> wrote:
> 
> Probably true - all of your points - but, INHO, this does not imply that the Internet should get access by default to most ports.

If it doesn't it isn't on the Internet. 

Many devices are - at best - tethered to the Internet by a proxy.  But that doesn't make it either right or sufficient.  

> And RFC 6092, REC-31 (for TCP), satisfies those needs.
> 
> But if the Internet can access an internal device, that should first be allowed by the "operator" of the CPE, as per RFC 6092, REC-48.
> And whoever is OK with that (open) policy, can make use of RFC 6092, REC-49, and go for "transparent" mode.
> 
> I acknowledge other contributions in this list stating that any device can end up with infected/hostile neighbors in the local network,
> but is this a reason/excuse to have a "mostly open policy for incoming traffic" ?
> 
> So, personally I cannot support publishing this draft as a WG document because it is, at least partly - but then : on an important point,
> in contradiction with RFC 6092.

See the beginning of sec 1.2 of that doc.  It informational only, despite the use of requirements language. 

> I would be more in favor if the approach chosen (blocking some ports) would have been to strengthen RFC 6092, REC-49 :
> "transparent mode", but not for all ports.

RFC 6092 carries zero weight. If you want to strengthen it, you need to start by having it be reconsidered and ultimately reissued as BCP or some such.  

Joe

> 
> 
>> On Sat, Nov 16, 2013 at 7:30 AM, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> wrote:
>> 
>> >________________________________
>> > From: Marc Lampo <marc.lampo.ietf@gmail.com>
>> >To: Mikael Abrahamsson <swmike@swm.pp.se>
>> >Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
>> >Sent: Thursday, 14 November 2013 9:50 PM
>> >Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC
>> >
>> >
>> >
>> >I realise now that "unsolicited" is a word allowing multiple interpretations (but also used in RFC 6092).  But we seem to have got it right.
>> >
>> >Anyway, the fact that some service, on an internal device, is willing to accept connections on port XYZ,
>> >does not, in my opinion, imply that those connections may also come from the outside Internet.
>> >Back to the example with the refrigerator :
>> >suppose it has a service (port XYZ) that allows it to be queried for its contents.
>> 
>> >Probably great when one is at home, but does this mean accessible from anywhere on the Internet ?
>> >
>> >In my opinion : not before the owner has explicitly instructed his CPE to allow incoming connections (RFC 6092, REC-48).
>> >
>> 
>> Actually, I think you're probably going to want your refrigerator to be able to access the Internet, as well as your toaster, answering machine, rice cooker, washing machine etc.
>> 
>> I think appliances, if they aren't already, are going to become computers, with as much done via software/firmware as possible, instead of hardware, because hardware is much harder and more expensive to change, both during development and after it is sold to the customer.
>> 
>> However, software/firmware is still hard to change if the customer has to either take it back to the manufacturer, or plug a PC or USB stick into it to update the software/firmware. Having the device be able to update itself over the Internet will be both much more user/customer friendly and much cheaper for the manufacturer. 
>> 
>> So manufacturers have an incentive to make their appliances be able to attach to the Internet, and their customers have an incentive to attach them. As with tablets and smartphones, the manufacturer won't be able to vouch for the existence of any upstream network "firewalls", nor will they successfully be able to ask the customer of their existence, so the manufacturer will have to assume the worst, and therefore harden the appliance against publicly addressed unfettered Internet access.
>> 
>> Regards,
>> Mark.
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops