[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



 

> -----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?

-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
>