Extending IPv4 with source translation/source privacy.
Skybuck Flying
The internet protocol version 4 could be extended with source
translation/source privacy.
The idea is as follows:
The ip.source is translated into something else/arbitrary along the path's
routers to it's destination.
Each router selects a random available ip from a table which is to replace
the ip.source of the packet.
A bit is set in the packet indicating the privacy option. This bit could be
bit 0 of the ip.flag, alternatively
it could also be an add-on option, the flag bit is to be preferred because
it would require little changes
to simple ip implementations.
If the router does not support this new option then the ip.source is left
intact.
Packets with the bit cleared are routed as normal.
Packets with the bit set indicate a special privacy packet and have to be
treated in a special way.
if ip.flag.bit0 is set it indicates a privacy packet then
if ip.TypeOfService.bit6 is set it indicates the ip.source is
translated.
if ip.TypeOfService.bit7 is set it indicates the ip.dest is translated.
Bit6 of ip.TypeOfService is used to indicate the ip.source is translated.
Bit7 of ip.TypeOfService is used to indicate the ip.destination is
translated.
These two bits are used to indicate if it's a regular/normal ip or a
translated ip.
Based on this information the router can make a decision if the packet is to
be routed freely/normally or if certain restrictions apply.
If the ip.TypeOfService.bit7 is set then a restriction applies. The router
can only route the packet towards the router which had the ip.dest
as an ip.source during previous transmissions/reception at the current
router.
Therefore each router on reception of a privacy packet must also remember
from which router it came. Therefore each ip.source (ip translated source)
is
unique per router and needs a seperate entry into the router's hash
table/data structure.
All translated ip's remain valid for a certain period of time which needs to
be standardized for example 5 minutes might be ok.
The goal of the idea is to keep the ip.source secret from end points of the
internet and also of other routers. At each stage/hops/router
that supports it translation happens, stages/hops/routers that don't support
it should function normally and still work:
A->B->C->D->E
C does not support translation.
A sends to E along path BCD.
Packet at A looks like:
ip.source = A
ip.dest = E
ip.flag.bit0 = 1
ip.tos.bit6 = 0
ip.tos.bit7 = 0
Packet at B looks like:
ip.source = Z
(z selected from ip_seen_table, (z not in ip_seen_table, z not in
translation tables))
(forward_translation_table[A].replacement = Z)
(backward_translation_table[Z].replacement = A)
ip.dest = E
ip.flag.bit0 = 1
ip.tos.bit6 = 1
ip.tos.bit7 = 0
Packet at C looks like:
ip.source = Z
ip.dest = E
ip.flag.bit0 = 1
ip.tos.bit6 = 1
ip.tos.bit7 = 0
Packet at D looks like:
ip.source = G
(G selected from ip_seen_table, (G not in ip_seen_table, G not in
translation tables))
(forward_translation_table[Z].replacement = G)
(backward_translation_table[G].replacement = Z)
ip.dest = E
ip.flag.bit0 = 1
ip.tos.bit6 = 1
ip.tos.bit7 = 0
Packet at E looks like:
ip.source = G
ip.dest = E
ip.flag.bit0 = 1
ip.tos.bit6 = 1
ip.tos.bit7 = 0
EndPoint E will believe the packet came from G.
EndPoint E wishes to communicate back to G which is actually A and proceeds
as normal and sends messages back:
EndPoint E does also not support privacy option therefore Packet E will send
the following:
Packet at E looks like:
ip.source = E
ip.dest = G
ip.flag.bit0 = 0
ip.tos.bit6 = 0
ip.tos.bit7 = 0
Packet at D looks like:
Router at D detects G and knows it was a translated IP, meanwhile it could
also have become the real G this is where it gets a little tricky.
if the real G was received by router at D and was also transmitted to E a
conflict has occured. This could be solved by translating conflicts
as well... therefore the real G could get a different IP for the time
being... which could further confuse E which is not desirable... so instead
the privacy "connection" is lost and the real G will prevail over the fake
G. The fake G can be removed and replaced with something else, resulting
in a short loss of a packet possibly a tcp connection and other udp related
connections... future protocols might need to be aware of suchs drops
and take it into account that it might happen, if clients start supporting
priacy option as well this might not be a problem anymore since the flags
will indicate if it was a translated ip or a real ip.
Anyway let's go on for a moment since these conflicts could be rare in
practice and might not really present that big of a problem...
As I was writing... the router at D detects G and translates it back via
it's backward translation table.
G is replaced with Z.
Since the router support privacy option, the E is also translated.
ip.source = Q
(Q selected from ip_seen_table, (Q not in ip_seen_table, Q not in
translation tables))
(forward_translation_table[E].replacement = Q)
(backward_translation_table[Q].replacement = E)
ip.dest = Z
ip.flag.bit0 = 1
ip.tos.bit6 = 1
ip.tos.bit7 = 1
Packet at C looks like:
ip.source = Q
ip.dest = Z
ip.flag.bit0 = 1
ip.tos.bit6 = 1
ip.tos.bit7 = 1
Router at C does not support privacy option and ignores it and routes the
packet forward to Z which came from the router at B.
Here another potential problem exists... if C does not copy over the tos
bits then B could get confused... I am not sure
what routers do and if they are allowed to modify tos bits from packets. If
they are allowed to modify tos bits than a solution
will have to be found, and some other kind of bits might have to be used. If
no solution can be found then perhaps this
idea could be implemented for ipv6 instead.
Packet at B looks like:
Router at B supports privacy option and applies it to the source as well...
Q is replaced with L
ip.source = L
(L selected from ip_seen_table, (L not in ip_seen_table, L not in
translation tables))
(forward_translation_table[Q].replacement = L)
(backward_translation_table[L].replacement = Q)
ip.dest = A
(Z is found in translation table)
(Z is replaced with A via backward translation table)
ip.flag.bit0 = 1
ip.tos.bit6 = 1
ip.tos.bit7 = 0
Bit7 could be turned off since it detected/found Z in table... and thus can
translate it back.
ip.tos.Bit7 could there prevent confusion among routers and to make them
understand if something is a real ip or a translated ip as to
be able to properly route real ip's. I am not completely sure if bit7 is
really required but I think so...
Further experimentation with this idea would give further insights if it's
required and I would expect so.
To me this idea seems usuable and workable in practice... so far I have
described two little potential problems and possible solutions... conflicts
between translated ip's and real ip's which would be rare, in such case the
privacy option/path could be dropped.
Copieing of the tos bits. Perhaps this is not really that big of a
problem... since B will find the translated IP in it's tables... it only
again becomes
a problem if a translated IP and a real IP is received at B, without the
proper tos bits set B might not have a way to determine if it was a
translated or
real ip, however it might still be able to understand it by looking at from
which router it received !
So additional solutions are thinkable and might still be available/possible.
Therefore I think this idea has merit, requires no changes to the packet
format itself. Only requires reinterpretation of the flag.bit0 which was
marked
as reserved, therefore it could be used.
Plus tos.bit6 and tos.bit7 is usually indicated as reserved/not used so also
seem free to be used especially in combination with flag.bit0 set.
The motivation for this idea is to protect internet users from harrassment
and lawsuits relating to copyright infringement and such.
Also to give internet users more privacy, and less snooping into their
lifes, and perhaps also to enlighten the role of internet service providers
so that they in all honesty can say that they don't know who sent what...
Bye,
Skybuck.
Skybuck Flying
The idea assumes that at each router a modest ammount of traffic passes it.
So the idea assumes that the router will see less than half of the total ip
range go past it.
The idea would fail if 50% of the total internet ip range passes a single
router and all ip's desire privacy option.
If such hot spots exist I don't know... perhaps the amsterdam exchange...
might have routers that see more than 50% of the total ip range ?
For such hot spots this idea would fail and those routers could simply not
support it, yet it would not have to be a problem... these would
simply be the C routers as described in the example... but not because they
don't support it... but because they can't support it because
of restrictions/problems... way too many ip's are seen... In such a case the
router could fall back to "does not support privacy option" and
could slowly back off from supporting it. New request for translation are
not processed, and simply passed on to the next router as usual.
Therefore the software can check if certain conditions are present which
doesn't allow it to any longer support the privacy option and has to fall
back to normal operation. Thus the software can be fully automated and
require no inspection by administrators/service personel... and can simply
be placed into use without too much further maintenance... perhaps an
occasional check by personal to see if the privacy operation is still in
affect
or not might be usefull for them to understand what's going on with their
router and provided service to end users... it might be usefull to further
split up the network/load on routers or so...
I would expect this rare situation to be an extreme but it cannot be ruled
out especially with the growth of the internet ! ;) And the software should
be flawless and take this restriction into account so it doesn't suddenly
fail if such an extremen situation where ever to occur ! ;) :)
Bye,
Skybuck :)
Skybuck Flying
translation" also known as NAT.
I'm a bit rusty about NAT but as far as I remember NAT works by using public
available resources like public ip addresses, and public ports and tries
to attach a single public ip address and multiple public ports to multiple
local ip addresses.
NAT is probably based on the idea of "public ip addresses" versus "local ip
addresses" and exploits that.
The difference with my idea is that instead routers exploit the
"non-seen-address-space" for translation/privacy.
As long as a router does not see a real ip/address it can use it as a fake
ip/address which will still work because it/the router will take
responsibility for the fake/ip address and act upon it when it receives it
from other routers which believe those fake ip addresses are real.
Here may lie a problem though... what if those other routers do see these
fake ip addresses which are actually real ip addresses... such routers might
start to route the fake ip/address wrongly... I am not sure how much of a
problem this is and if it can be solved somehow... maybe by some smart
routing/information/bgp tricks or something... but it's definetly something
to be aware of and look into... it might put a kink in the cable for this
idea ?! ;) :)
Bye,
Skybuck.
Skybuck Flying
would/could only be a kink in the cable for ipv4... not for newly designed
protocols
perhaps ipv6 can still be modified or future protocols.
Perhaps those future protocols could reserve a part of the address space for
"fake addresses" for privacy.
Bye,
Skybuck.
glen herrmannsfeldt
> The internet protocol version 4 could be extended with source
> translation/source privacy.
(snip)
There is already a system for doing this, though not at the IP level.
It is available for those protocols for which it seems useful.
It would be a lot of work, and little gain, to do it for
protocols that it isn't needed for.
-- glen
Mok-Kong Shen
[snip]
> Packets with the bit cleared are routed as normal.
>
> Packets with the bit set indicate a special privacy packet and have to be
> treated in a special way.
A presumably very dumb argument from an ignorant: You are apparently
modifying a standard and that's generally not a good idea IMHO except
though the standardization gremium. I can't strongly argue in the
field of data transmission because my knowledge there is extremely
poor, but in the presumably akin field of standardization of
programming languages I am personally very convinced that any
modification of the standard outside of a standardization organization
isn't a favourable undertaking for the benefit of the 'entire' user
community.
M. K. Shen
Ken Hagan
<IntoTh...@hotmail.com> wrote:
> The ip.source is translated into something else/arbitrary along the
> path's routers to it's destination.
There's your mistake. You cannot talk about "the" path from source to
destination because in general there are multiple paths and different
packets in the same TCP flow might travel by different routes.
NAT, which you mention in a later post, only works because everyone in the
private address space is behind a single router. (One could presumably
implement some sort of co-operative NAT if you had multiple boundary
routers, but this certainly isn't how it works in the average home or
small office.) That single router is, of course, also a single point of
failure, so your proposal actually depends on something that some people
would reckon was a problem.
Skybuck Flying
"Ken Hagan" <K.H...@thermoteknix.com> wrote in message
news:op.virck...@khagan.ttx...
> On Thu, 09 Sep 2010 06:25:49 +0100, Skybuck Flying
> <IntoTh...@hotmail.com> wrote:
>
>> The ip.source is translated into something else/arbitrary along the
>> path's routers to it's destination.
>
> There's your mistake. You cannot talk about "the" path from source to
> destination because in general there are multiple paths and different
> packets in the same TCP flow might travel by different routes.
While I did not think of multiple paths the idea would still work.
The packets from a flow could be routed among different paths and get their
own treatment.
The end result would be that the destination/end point gets packets from it
would seem
different sources, for a tcp protocol this could be a problem.
But for for example P2P application like BitTorrent it doesn't really matter
where a packet came from.
Especially for the UDP variant I would presume ;)
So for TCP the ip.flag.bit0 might not be usefull but for other protocols it
might still be usefull ! ;) :)
Bye,
Skybuck.
Philip Paeps
> it could also be an add-on option, the flag bit is to be preferred because
> it would require little changes to simple ip implementations.
Note that requiring *any* changes to existing implementations is pretty much a
no-go. There are plenty of IP devices out there which can never be upgraded.
> To me this idea seems usuable and workable in practice... so far I have
> described two little potential problems and possible solutions... conflicts
> between translated ip's and real ip's which would be rare, in such case the
> privacy option/path could be dropped.
Your scheme requires that routers process packets in software and keep a table
of translations which could potentially grow very large, particularly since it
is impossible for routers to know when translations could be 'expired'.
There are plenty of methods for enabling privacy on a higher (and much more
practical) level. Take a look at the Tor project, for instance.
- Philip
--
Philip Paeps Please don't email any replies
phi...@paeps.cx I follow the newsgroup.
Jorgen Grahn
On Thu, 2010-09-09, Skybuck Flying wrote:
>
> "Ken Hagan" <K.H...@thermoteknix.com> wrote in message
> news:op.virck...@khagan.ttx...
>> On Thu, 09 Sep 2010 06:25:49 +0100, Skybuck Flying
>> <IntoTh...@hotmail.com> wrote:
>>
>>> The ip.source is translated into something else/arbitrary along the
>>> path's routers to it's destination.
>>
>> There's your mistake. You cannot talk about "the" path from source to
>> destination because in general there are multiple paths and different
>> packets in the same TCP flow might travel by different routes.
>
> While I did not think of multiple paths the idea would still work.
>
> The packets from a flow could be routed among different paths and get their
> own treatment.
>
> The end result would be that the destination/end point gets packets from it
> would seem
> different sources, for a tcp protocol this could be a problem.
It would break TCP.
> But for for example P2P application like BitTorrent it doesn't really matter
> where a packet came from.
> Especially for the UDP variant I would presume ;)
UDP-based protocols keep state too, and are just as picky about where
the datagram came from as TCP. You cannot expect every datagram to
contain full context, so the application protocol uses the source
address:port (and maybe destination too) as a key to lookup state for
the "conversation".
Also, please don't cross-post to irrelevant groups. This has nothing
to do with Winsock programming, crypto or Ethernet.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Skybuck Flying
news:slrni8h9qs.hou...@rincewind.paeps.cx...
> Skybuck Flying <IntoTh...@hotmail.com> wrote:
>> it could also be an add-on option, the flag bit is to be preferred
>> because
>> it would require little changes to simple ip implementations.
>
> Note that requiring *any* changes to existing implementations is pretty
> much a
> no-go. There are plenty of IP devices out there which can never be
> upgraded.
The idea is to keep using those old devices and add new devices which would
enable
the privacy.
Only one device in the path is needed to give some form of privacy.
Existing devices would remain compatible.
This is something which needs to be tested or looked into, to see how
existing
devices would behave with the new slightly different packets.
Main question is:
Do existing devices simply copy the existing TypeOfService field ?
>> To me this idea seems usuable and workable in practice... so far I have
>> described two little potential problems and possible solutions...
>> conflicts
>> between translated ip's and real ip's which would be rare, in such case
>> the
>> privacy option/path could be dropped.
>
> Your scheme requires that routers process packets in software and keep a
> table
> of translations which could potentially grow very large, particularly
> since it
> is impossible for routers to know when translations could be 'expired'.
The translations expire after 5 minutes of not being used anymore.
When a translation occurs it's "expiration timer" gets reset.
How much memory is needed remains to be seen, how much memory do routers
have these days ?
The cost of memory is not that high... an ISP wanting to provide some form
of privacy could
add a slightly more expensive router.
> There are plenty of methods for enabling privacy on a higher (and much
> more
> practical) level. Take a look at the Tor project, for instance.
Tor ain't that great, last thing I heard about it it got broken and
compromised ;)
Bye,
Skybuck.
jbriggs444
> "Philip Paeps" <philip+use...@paeps.cx> wrote in message
>
> news:slrni8h9qs.hou...@rincewind.paeps.cx...
>
> > Skybuck Flying <IntoTheFut...@hotmail.com> wrote:
> >> it could also be an add-on option, the flag bit is to be preferred
> >> because
> >> it would require little changes to simple ip implementations.
Burn that bit for this purpose? No freaking way.
> Do existing devices simply copy the existing TypeOfService field ?
The low order two bits in the ToS field are spoken for.
http://en.wikipedia.org/wiki/Explicit_Congestion_Notification
in particular:
"Cisco IOS routers perform ECN marking if configured with the WRED
queuing discipline since version 12.2(8)T."
So no, existing devices do not simply copy the ToS field.
[...]
> How much memory is needed remains to be seen, how much memory do routers
> have these days ?
We're running 2 gig on our Internet edge router. But there's no way
we'd throw memory
and processor horsepower at what amounts to a huge NAT table that
would do nobody
any particular good.
> The cost of memory is not that high... an ISP wanting to provide some form
> of privacy could
> add a slightly more expensive router.
What's in it for the ISP? The ability to launder the IPs of its own
clients so that
complaints directed toward the ISP cannot be traced to individuals and
an
effective resolution but must instead involve subjecting the ISP to
the Usenet
Death Penalty? The ability to launder the IPs of others on the
Internet so that
the ISP's user community is subject to untraceable attacks instead of
traceable
ones?
Yes. I can see a niche ISP going into business to support a user
community
that wishes to remain anonymous. But there's nothing stopping that
ISP from
going into that business today without any changes to IPv4 at all.
Nothing
stops the ISP from doing NAT at his egress interfaces.
Perhaps you are after a technology that stops the rest of us from
blacklisting
such an ISP? Why should we help you in that endeavor? What's in it
for us?
Skybuck Flying
1. Maintaining user base, disconnected users because of copyright violations
are a loss.
2. Competitive adventage, customers might choose the ISP which can provide
more privacy for free, no additional costs.
3. Perhaps even no expensive lawsuits.
For data centers:
1. Maintaining server base, confisquated servers could also mean a loss.
Bye,
Skybuck ;) =D
Skybuck Flying
Yes. I can see a niche ISP going into business to support a user
community
that wishes to remain anonymous. But there's nothing stopping that
ISP from
going into that business today without any changes to IPv4 at all.
Nothing
stops the ISP from doing NAT at his egress interfaces.
"
That might not be true.
NAT can cause problems for software.
An ISP always applieing NAT could be problematic for end
users/clients/software.
With my idea it becomes possible to switch between "public" operation and
"private" operation.
New software could therefore make use of the new privacy mode by setting the
ip.flag0 bit ;) :)
Bye,
Skybuck =D