Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

On 2008-08-25 14:38, Dan Wing wrote:
>  
> 
>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org 
>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter
>> Sent: Sunday, August 24, 2008 2:05 PM
>> To: Mark Smith
>> Cc: jhw@apple.com; IPv6 Operations
>> Subject: Re: Some suggestions for 
>> draft-ietf-v6ops-cpe-simple-security-03
>>
>> Hi Mark,
>>
>> On 2008-08-24 23:15, Mark Smith wrote:
>> ...
>>> 2.2.  Internet Layer Protocols
>>>
>>> "Therefore, this document recommends the DEFAULT operating mode for
>>> residential IPv6 simple security is to permit all virtual private
>>> networking tunnel protocols to pass through the stateful filtering
>>> function.  These include IPsec transport and tunnel modes as well as
>>> other IP-in-IP protocols."
>>>
>>> Would it be better to restrict this to authenticated tunnelling
>>> protocols? Wrapping a malicious packet inside a GRE or IP packet and
>>> having the CPE blindly forward it would seem to me to be a really
>>> simple and easy way to bypass all the security mechanisms that this
>>> draft is defining.
>> I would object to that. That amounts to default-deny for all
>> the commonly used ways of bypassing ISPs that don't support
>> IPv6, and that would be a Bad Thing.
> 
> You're saying that the Simple CPE Security document is not intended
> to provide security, but rather intended to provide a way to receive
> unsolicited IPv6 traffic through non-IPv6-capable SPs?

If a host behind the CPE chooses to set up an IPv6 tunnel to
an IPv6-supporting ISP, I don't see that the tunnel is anybody's
business but the host's. So yes, in that case I think the CPE
should step back, because the host *is* soliciting incoming
packets.

    Brian

> 
> -d
> 
>> I think a recommendation that CPEs should document and warn about
>> such risks is a good idea, rather in the manner of personal
>> firewalls that alert you the first time you try to tunnel out
>> with Protocol 41, but remember when you click OK. Can we recommend
>> default-warn rather than either default-deny or default-allow?
>>
>> ...
>>> A few thoughts related to general tunnel security. Is it 
>>> appropriate for this draft to document...
>> How about referring to draft-ietf-v6ops-tunnel-security-concerns?
>> We should probably concentrate those issues in one place.
>>
>>    Brian
>>
> 
>