one-to-many messaging
Tom Thomson
ukcrypto at chiark.greenend.org.uk
Mon, 14 Apr 2008 20:14:17 +0100
> Sgriobh James Firth
>
> If an ISP sells a service called "Internet without VoIP" then the
> interception would be lawful under 3(3).
That's unquestionable.
> I bought the T-mobile service. It was clearly labelled as such. They
need
> to look at port numbers to provide that service.
Fair enough - clearly lawful.
> As I've said in previous posts, port numbers have their history in
> service type identifiers, which in all other communications networks
> are classed as traffic data (at least understood by professionals as
> such, IANAL).
>
> Port numbers SHOULD be classed as traffic data. The idea that data
> should be routed solely on IP address is outdated.
It's very hard to classify port numbers as traffic data in an IP
network, where they don't exist. Not all protocols at layer 4 use
anything like TCP or UDP port numbers. What happens if I choose to run
pretty well anything other than TCP or UDP? What happens for example if
I choose to run ISO Transport Class 4 over IP instead of TCP (you might
have a low opinion of people who choose to do that - but people were
using that protocol over multiple parallel multi-gigabit pipes to
emulate shared store [using distributed store with partial multiple
copies] for high-powered SMP and using it to connect very fast discs as
well back when TCP was still struggling to understand flow control, so I
don't think it would be a foolish choice at all)? If the port number is
traffic data clearly your IP network can't cope with any of that
traffic, because it doesn't have all the traffic data - so it's not an
IP network at all, but a something else network. Maybe we could call it
a TCP/UDP network?
I for one am glad that the days when using an odd port number between 99
and 113 meant "route me via UCL to one of the 8 non-TCP Janet niFTP
sites that we need to communicate with". I don't want to go back there.
I guess that's the sort of thing you are referring to as history?
As for service type identifiers - please recall that IP has a field near
the front of the header called "Type of Service". What I would like to
see is this field being used properly (and ideally for the use of it to
be defined in ISP contracts, and maybe for it to have a significant
impact on pricing). That works fine both for |TCP/UDP traffic and for
non-TCP/UDP traffic, and port numbers don't.
> > Same goes for P2P - but here the ISP may find it easier to make the
case
> > that it's legal interception.
>
> How so? Are you talking about shaping or detection of copyright
> infringement?
Shaping - I think the case for having to shape P2P is generally better
than the case for having to shape VoIP (but I wish ISPs would write
contracts that said what they were going to provide and what shaping
they would do).
> > The "is the port number traffic data" question is about whether the
port
> > number is used by the public telecommunications system to determine
the
> > DTE to which the communication is addressed
>
> Not so. Clearly includes intermediate equipment and means of
transmission
> decisions also, despite what was said in previous posts in relation to
> quality/priority and jitter reduction.
>
> 2(9)(b) any data identifying or selecting, or purporting to identify
or
> select, apparatus through which, or by means of which, the
communication is
> or may be transmitted,
You are right, I had omitted that. So what the traffic data covers is
routing through the public telecommunications system up to the interface
to the destination DTE (which is not in the public system).
>
> >- I reckon that choosing
> > between different apparatus beyond the DTE is going on outside the
> > public telecommunications system, so even where that happens (it
will
> > for most internet traffic, I imagine) that doesn't make the port
number
> > traffic data.
>
> But this does not always have to be so. A public network could offer
> subscribers the ability to route to DTE based on port number, a kind
of
> virtual firewall/portmapper. The firewall/gateway doesn't always have
to be
> private.
>
I agree that it's perfectly possible for the public service provider to
provide the firewall and onward routing on the inside of it. I'm a
little less sure that this leaves the firewall and the bits inside that
do routing as part of the public telecommunications service, although if
I have a big chunk of Norton kit (maybe Cisco, not sure it will cut it
though) I could provide firewall service for quite a few different
groups whose data must be kept separate. As a user I might not like
that idea, though, so maybe the ISPs won't do it - has anyone done it
yet? And the addressing on the inside is usually private not public
(that of course could change with IP v6).
M.