Default security functions on an IPv6 CPE

[Dan Wing]

> -----Original Message-----
> From: ipv6-ops-bounces+dwing=cisco.com at lists.cluenet.de [mailto:ipv6-
> ops-bounces+dwing=cisco.com at lists.cluenet.de] On Behalf Of Nick
> Hilliard
> Sent: Friday, June 03, 2011 4:24 AM
> To: Steinar H. Gunderson
> Cc: S.P.Zeidler; ipv6-ops at lists.cluenet.de; Gavin McCullagh
> Subject: Re: Default security functions on an IPv6 CPE
> 
> On 02/06/2011 18:39, Steinar H. Gunderson wrote:
> > Den 2. juni 2011 16:29 skrev Nick Hilliard<nick at foobar.org>
> følgende:
> >> Anyway, it's a good thing that we've learned from this mistake and
> aren't
> >> designing any more protocols or protocol extensions which encode
> endpoint
> >> identifiers inside the data stream.
> >
> > Who is “we” here? For sure, BitTorrent, Skype, and lots of different
> > gaming protocols do this, and are in wide use. After all, how else
> > would you initiate peer-to-peer communication?
> 
> Thing is, it doesn't really matter if a bunch of bittorrent streams
> fail to
> materialise because of endpoint connectivity loss.  And Skype works
> around
> things by using an arsenal of nat / firewall bypass tricks, several of
> which require third party arbitration, and all of which are pretty
> smart /
> ugly (i.e. fragile).  For the gaming protocols, are you referring to
> WoW?
> That's just bittorrent - again, it makes no real difference if a couple
> of
> streams fail for whatever reason.  Same with other p2p protocols.
> 
> So yeah, encoding endpoint information works but only if you're
> prepared to
> accept or work around extremely high levels of breakage.  In the case
> of
> FTP and SIP, we put in application level protocol interpreters and do
> things like opening dynamic ports and so on.  These often work
> reasonably
> well, although it means that we need to accept that we cannot use
> strong
> encryption for the control communication.  This sucks.

By "application level protocol interpreters", I think you are referring 
to ALG, which inspect and modify (SIP) signaling traffic.  For SIP
there are two ways to avoid ALG:  use a Session Border Controller (SBC)
all of which include a feature commonly called 'latching' (*) which 
eliminates the need for any ALG, or use ICE (RFC5245) on the 
endpoints.  As both eliminate the need for ALG, the SIP signaling
can be encrypted with TLS or DTLS.  Skype signaling (and media) is 
encrypted, as everyone knows, so it is demonstrably possible to 
build a system of components that do NAT traversal with encrypted
signaling and without cooperation by the NAT - a philosophy shared
by SBCs and ICE.


Why does that matter for IPv6?  SBCs are a likely path forward for
migrating SIP from IPv4 to IPv6, and ICE is the IETF's documented
path forward for migrating SIP from IPv4 to IPv6 (**).

(*) http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-03#section-5.1
(*) http://tools.ietf.org/html/rfc6157

-d