Microsoft files EU Android complaint

[James Knott]

D. Hugh Redelmeier wrote:
> | From: James Knott <james.knott-bJEeYj9oJeDQT0dZR+AlfA at public.gmane.org>
>
>
> | SIP can use various encryption methods, including IPSec, TLS and others.
>
> One automatically thinks choice is good.  But for interoperation, it
> just isn't.  We want everyone to have a common
> encryption/authentication/privacy/security/... so that they can
> interoperate.

Actually, there's a bit of history, where choice is available.  For 
example, with VoIP, you often have a choice of codecs and the app 
chooses the best common one, though it's also possible to select, such 
as G.729a for low bandwidth, G.711 for toll quality or even one that can 
provide broadcast quality.  There are other situations where multiple 
methods are available.
>
> In IPSec, a lot of the interoperation rigmarole that makes it hard to
> set up is
> (a) the options, and
> (b) the awkward ways to configure most implementations, and
> (c) the awkward way that IKE negotiates.
>
> IKEv2 was meant to address this but I don't know if it succeeds, and
> it isn't generally used.
>
> Combinatorial complexity of a program makes it very hard to test all
> cases.  This is VERY bad from a security standpoint.  Options create
> such combinatorial complexity.

IPSec has been in use for a while and seen a lot of testing.  There are 
different ways to configure it.  For example, I have used shared secret 
passwords with several VPNs,  You can also use public/private keys, in 
the same manner as ssh, certificates, as is used with several services 
or a key server.  IPSec supports them all and you choose which ever is 
best for the application.
>
> |  I
> | mentioned IPSec because it is a standard part of IPv6 and moving to IPv6 will
> | provide benefits to VoIP, such as Mobile IPv6, mandatory CoS, along with lower
> | latency provided by routing improvements.
> That doesn't seem like what you said. I don't remember you mentioning 
> IPv6 in messages I've responded to. IPSec is part of most IPv4 stacks 
> already (Linux, Windows, OS X, *BSD, and iOS already have IPSec under 
> IPv4; I think Android does too).

I didn't mention IPv6 specifically in that message, but I have on many 
other occasions, both here and elsewhere.  I have been running IPv6 
myself for almost 3 years and my home network is fully functional with 
it (I have a /56 subnet, which is 2^72 addresses or about a trillion 
times the entire IPv4 address space).  Regardless, IPSec is available on 
both IPv6 and IPv4 and is becoming the standard for many uses beyond 
VPNs.  Also, IPSec was originally developed for IPv6 and then adapted to 
IPv4.  My Android phone and tablet both support IPSec, PPTP and L2TP.  
They also can use IPv6 when connected to my home network and my phone 
will also be able to when Rogers gets around to offering IPv6 on their 
cell network.

Unlike with IPv4, CoS is mandatory with IPv6.  This means that when you 
use it with VoIP, your call will be given priority over other traffic on 
the Internet.

> The rest of the improvements seem to be minor improvements as far as 
> VoIP is concerned. Unless CoS works surprisingly well. Oh, and if NAT 
> goes away, that would be really good for peer-to-peer phone calls 
> (that should be the norm).

The routing improvements (hierarchical routing, fixed length header 
etc.) reduce latency for all traffic, not just VoIP, but reducing 
latency is one of the goals when you're using it.

> Other than that, IPSec can support SIP, not the other way around. We 
> (the FreeS/WAN project) talked about creating a userland API so that 
> an application could request or require that a socket be carried over 
> IPSec. We never got there and I don't know of any other implementation 
> that has done that. Allowing applications to require secure channels 
> does seem like a useful facility.

Compare VoIP using IPSec to the way browsers, email (or even VoIP) etc. 
use ssl.  It just provides encryption and authentication on a per 
application basis, rather than an encrypted tunnel, when used in a VPN, 
which leaves the contents unencrypted outside of the VPN.  I have never 
used FreeS/WAN, but I'm in the process of setting up a StrongSWAN VPN 
between my notebook and home network, to see how well it supports IPv6.  
Then I'll include my tablet, which already has the StrongSWAN software 
installed.  If that works with IPv6, then I'll be able to access the 
computers on my home network from my tablet, regardless of whether IPv6 
is otherwise available.  I also have the 6in4 tunnel software installed 
on my notebook, so I can use IPv6 to access my home computers when 
elsewhere (other than the Mississauga library & community centre WiFi, 
where everything other than http port 80 is blocked).  As for those 
implementations you mentioned not supporting applications, that may be 
because they're designed to be used as a VPN and not for directly 
supporting apps.  Are the required pieces available to be called by an 
app? Perhaps we'll have to see what Cisco and others do with this.  
Cisco routers certainly support IPSec, but I haven't worked at that 
level with their phones.  Many of the soft phone apps support some form 
of encryption.

--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists