BBC News - 'Fresh proposals' planned over cyber-monitoring

[Andrew Cormack]

> -----Original Message-----
> From: ukcrypto-bounces at chiark.greenend.org.uk [mailto:ukcrypto-
> bounces at chiark.greenend.org.uk] On Behalf Of Ian Batten
> Sent: 10 May 2013 15:04
> To: UK Cryptography Policy Discussion Group
> Subject: Re: BBC News - 'Fresh proposals' planned over cyber-monitoring
> 
> 
> On 10 May 2013, at 11:42, Roland Perry <lists at internetpolicyagency.com>
> wrote:
> 
> > In article <518CB006.8000604 at iosis.co.uk>, Peter Tomlinson
> <pwt at iosis.co.uk> writes
> >> The internet service provider (ISP) has announced that it is
> currently piloting technology called Carrier-Grade Network Address
> Translation (CGNAT) that will see as many as nine different customers
> share the same IP address.
> >
> > Mobile networks use carrier-grade NAT as well, so the technique is
> well understood.
> >
> >> BT said it is trialling CGNAT in a bid to make the most efficient
> use of existing "IPv4 internet address", which are currently "running
> out", before new "IPv6 addresses become widely adopted". Doing so will
> enable fixed-line internet customers to stay connected, it said.
> >
> > God forbid they roll out IPv6 instead :(
> 
> Of course, they'd need a CGNAT (I've never really understood how that
> differs from plain NAT) solution there, because most of the Intertubes
> aren't accessible with pure IPv6.
> 
> ian

My colleague explained it as CG means better management etc. as well as more robust performance. It's also supposed to incorporate features that make it likely the world will keep working if there are multiple NATs in a chain or if applications make unjustified (but usually correct in an end-to-end world) assumptions about the allocation of addresses and ports. See draft RFC4787 (http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-10), for example.

It seems you may also end up using different algorithms for allocating ports: e.g. the BT system seems to do *static* allocation of a few thousand ports to each user so, for example 127.0.0.1:1-5000 will always be Andrew whereas 127.0.0.1:5001-10000 will always be Ian. Matching a connection to a user is therefore trivial, with almost no logs :-) Whereas on the consumer/business NATs I've had to deal with the addresses and ports may be allocated dynamically on demand as each TCP connection comes in, so you have massive logs and a big time-sync problem (ah, see REQ14 of the RFC draft!)

I *think* the static approach also means that Ian can run out of port mappings without affecting Andrew, whereas on a dynamic NAT once we all together approach 65536 mappings, we all together start failing. I guess that's also a nice feature if you're a service provider.

Nice to be sent off to read RFCs and discover I can still understand them, BTW ;-)

Andrew