Perry Lorier's comments on CPE drafts

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

Forwarded with permission.

    Brian

-------- Original Message --------
Subject: Re: [Ipv6-techsig] [spam?] Various IPv6 bits and bobs
Date: Sun, 01 Nov 2009 13:52:29 +1300
From: Perry Lorier <perry@coders.net>
Reply-To: ipv6-techsig@listserver.internetnz.net.nz
To: ipv6-techsig@listserver.internetnz.net.nz
References: <8df701f90910281853m5a0e993ft4438a9cc2d5bd9f4@mail.gmail.com>	<4AE8FFAD.4060601@gmail.com>

Brian E Carpenter wrote:
> Dave,
>
> Are the vendors aware of the developing specs for CPE functionality
> and security, or are they making it up as they go along?
>
> draft-ietf-v6ops-ipv6-cpe-router
>   

WPD-3: If the delegated prefix is an aggregate route of multiple,
more-specific routes the IPv6 CE router MUST discard packets  that match
the aggregate route, but not any of the more- specific routes.

Not send ICMP6 Destination network unreachable?  I guess they're trying
to stop people from mapping which segments are in use?  But if a network
is in use, but the host isn't there then it's going to reply with ICMP6
Destionation host unreachable when neighbour discovery times out?



> draft-wbeebee-v6ops-ipv6-cpe-router-bis
> draft-ietf-v6ops-cpe-simple-security
>   
REQ-7: By DEFAULT, packets with unique local source and/or destination
addresses [RFC4193] SHOULD NOT be forwarded to or from the exterior network.

This seems short sighted.  An ISP should firewall these packets, having
the CPE do it means theres no way for an ""ISP"" (well upstream) to have
some of it's services sitting inside ULA space which it provides to its
downstream clients.  This could be used for local servers (such as
recursive DNS servers) that shouldn't be reachable from the rest of the
Internet, but it's obviously diserable for their downstream clients to
be able to reach.  Promoting ULA as a simplistic security measure
limiting the scope of your traffic seems like a wise approach, don't
just let it be usable by leaf networks, let ISP's use it too.

REQ-40: Gateways SHOULD implement a protocol to permit applications to
solicit inbound traffic without advance knowledge of the addresses of
exterior nodes with which they expect to communicate.

As a sometimes-application-level-programmer I'm wary that these
requirements make my job of writing applications very difficult.  If I
want to write something which at least appears to be "peer to peer" then
I'm stuck with a few options:

* Implement all the protocols that REQ-40 suggests "might be applicable".

These protocols are all at best still in draft.  I also need to hope
that my end users have one of the CPE's that implements REQ-40 for at
least one of the protocols I've implemented.

* Try and make UDP/TCP/SCTP/DCCP NAT Traversal work.

Note that while there is a lot of "trial" and "test" TCP NAT clients
around I'm unaware of anybody actually using TCP NAT Traversal "in the
wild".   I've not seen anyone seriously attempt SCTP nat traversal.

NAT Traversal also requires either I have to have a server somewhere out
on the Internet that isn't behind a CPE that can work as an
intermediate,, or the use of intermediate servers that aren't yet fully
specified (such as draft-ietf-behave-turn), and AFAIK there is no
standard for DCCP/SCTP or other protocol intermediates.

In SCTP NAT traversal is at best "tricky" (and I mean tricky compared to
TCP nat traversal which isn't exactly a walk in the park either).  For
DCCP I believe it's impossible.

In fairness draft-ietf-v6ops-cpe-simple-security specifies things in a
way that means NAT traversal for UDP/TCP/SCTP should just work.  But as
far as I can tell noone really has tried other than for UDP.  This
appears to be the current "recommended" way of dealing with the problem (!).

* Try and do everything over a Tunnel system such as IPsec.

I thought this sounded like a very natural way of sending traffic
around, and cpe-simple-security says that IPsec traffic must be passed
unimpeded.  Negotiating Address/Port/Security Association between peers
has a certain appeal to it.  And as an added bonus it can be encrypted,
or at least signed to prevent forgery or middlebox meddling. However in
current implementations you need extra privileges to create IPsec
Security Associations, which is beyond the privileges of a normal user.
This is a pity, as this sounds like a particularly nice and elegant
solution.

* Ask users to add port forwards to their CPE's like they do today.
Rely on users being able to understand what you're asking for.

* Try and convince people to stay off native v6 and use Teredo which has
slightly difference security models implemented in the host.

None of these sound particularly appealing to me as an application
developer.  I'm going to need to spend a lot of time and effort working,
testing and developing for something thats not directly related to the
goal of my application.  This also seems fragile as most of these things
are outside of my control (which protocols the CPE implements for
allowing incoming connections, aquiring and testing TURN servers,  the
likelyhood that middleboxes or even end hosts correctly deal with TCP
simutanious open, the protocol design of DCCP).

Am I missing something obvious here?

My preferred solution to CPE would be to only allocate ULA addresses to
hosts, unless they specifically request otherwise.  Thus your network
printer that you don't want reachable over the Internet, is only
reachable via the locally scoped ULA range.

I'd add a AI_GLOBAL flag to getaddrinfo() that means that this
connection may be globally accessible/routable.  Thus if you bind using
getaddrinfo() using AI_PASSIVE, you get a list of link local and ULA
addresses you can bind to.  AI_GLOBAL|AI_PASSIVE then lets you bind to
link local, ULA and globally scoped addresses.  Thus applications, on a
per socket basis can describe their security needs.  By making the less
secure (AI_GLOBAL) version require adding more flags, this would mean by
default people would not get put on the global Internet.  In this case
local file sharing wouldn't use this flag, and thus wouldn't be
accessible from over the Internet, and people running web servers could
enable this flag, thus allowing webservers to be accessible from
anywhere.  (Obviously this should be a configuration option for your
webserver, maybe you don't need your site announced that far).

Another version of the above solution would be to have a couple of bits
reserved in the sin6_scope_id for specifying which scopes are acceptable
for this address.  eg SIN6_SCOPE_GLOBAL = 0x8000000.  Thus if you don't
set sockaddr_sin6.sin6_scope_id = 0 | SIN6_SCOPE_GLOBAL; then you end up
with a locally scoped socket.

These require code changes to all v6 apps that are around today, to make
them continue to work but they aren't large changes.  But it is a rather
major overhaul.   Windows already does more or less this with its
IPV6_PROTECTION_LEVEL socket option
(http://msdn.microsoft.com/en-us/library/aa916826.aspx).

Another less invasive solution would be to extend the BSD sockets API To
allow a setsocketopt(2) of IP_ADD_SA / IP_DEL_SA to add/delete security
associations for a specific socket, thus applications that want to
extend what they currently do today to include IPsec and thus v6 CPE
transversal could easily do so.



_______________________________________________
IPv6-techsig mailing list
IPv6-techsig@listserver.internetnz.net.nz
http://listserver.internetnz.net.nz/mailman/listinfo/ipv6-techsig