Re: I-D.ietf-v6ops-cpe-simple-security-09

[Mark Smith <[e-mail]>]

On Mon, 22 Mar 2010 08:58:06 +0100
Mark Townsley <[e-mail]> wrote:

> On 3/21/10 11:14 PM, Brian E Carpenter wrote:
> >
> > As a co-author of 4864, let me agree violently. It's not a BCP.
> > Even if it was, consensus could reverse it.
> >
> > What 4864 says is: NATs weren't designed as security devices but they
> > provide simple security by blocking everything incoming by default.
> > To implement simple security for v6 you should do it with a stateful
> > firewall.
> >    
> Right, NAPTs were invented primarily for address amplification, but also 
> brought simple security and address independence.
> 

I agree. The security (I'd like to put that in quotes, but there is a
fair bit of it) of NAPT wasn't by design, but as a consequence of 
the nature of it's operation. It is default deny because it is
impossible for it not to be.

RFC4864, despite it's more politically correct name (can't remember
the earlier more accurate, albeit controversial one), is about exactly
replicating the security functions of IPv4 NAT that people have come to
expect, using IPv6 methods - because they couldn't "expect" anything
else. From the Abstract:

"  Although there are many perceived benefits to Network Address
   Translation (NAT), its primary benefit of "amplifying" available
   address space is not needed in IPv6.  In addition to NAT's many
   serious disadvantages, there is a perception that other benefits
   exist, such as a variety of management and security attributes that
   could be useful for an Internet Protocol site.  IPv6 was designed
   with the intention of making NAT unnecessary, and this document shows
   how Local Network Protection (LNP) using IPv6 can provide the same or
   more benefits without the need for address translation."

IOW, if you really want to exactly replicate IPv4/NAT type security in
IPv6, this is how you do it.

I think the CPE draft, OTOH, should be saying "this is how you should be
doing security in IPv6". I think restoring end-to-end, at least
partially or configurably fully, is a key requirement. I think the CPE
draft already does that. Arguably, that also already makes it inferior
to IPv4/NAPT, because end-nodes will be directly visible over the
Internet. However, we also know that end-nodes are much more security
aware and capable than they used to be, so we're able to loosen CPE
security to help restore end-to-end because we know that modern
end-nodes are going to take up the slack. The CPE becomes a security
assistant, not a security authority.

This is why I've thought a bit more definite problem statement would
help. If it is purely to replicate IPv4/NAPT CPE functionality in IPv6,
then either RFC4864 would already do, or possibly a slightly more CPE
oriented version needs to be produced. If, however, it is to state
"this is how IPv6 CPE security should be done", then I think we should
leave legacy IPv4/NAPT concepts that aren't appropriate behind.

Regards,
Mark S.

> Address amplification is something that IPv6 currently does not need, 
> and address independence is something that would be quite useful but we 
> haven't been able to design and deploy it without breaking end-to-end.
> 
> The firewall function in simple-security explicitly damages end-to-end. 
> If we go this route, we might as well toss in NAT too as we will have 
> already paid the price in terms of end-to-end transparency; We might as 
> well get the address independence benefit along with it.
> 
> I suspect this will be used as an argument in the future if stateful 
> firewall operations become ubiquitous in CPEs: How is NAT *that much* 
> worse than the firewall you already have?
> 
> - Mark
> > It doesn't say that CPEs MUST do this. It leaves that choice open, as
> > an informational document.
> >    
> 
> >      Brian
> >
> >    
> 
>