[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: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Brian E Carpenter
> Sent: Sunday, August 24, 2008 2:05 PM
> To: Mark Smith
> Cc: email@example.com; IPv6 Operations
> Subject: Re: Some suggestions for
> 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?
> 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.