Subject: [geonet/its] Presentation of draft about geolocation in IPv6 headers - 6MAN Working Group

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Nov 2014 05:18:46 +0100

Hello,

Friday morning there will be a presentation about using geolocation 
information in IPv6 headers, in the 6man Working Group.
https://tools.ietf.org/wg/6man/agenda?item=agenda-91-6man.html

The draft is http://tools.ietf.org/html/draft-skeen-6man-ipv6geo

What do you think about this draft?

Alex

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 13 Nov 2014 12:10:16 -0800

Alex,

The ID is a good first step -- it illustrates at least one way to encode
Lat/Lon/Alt at layer 3.  IPv6 certainly has the flexibility to do
such.  
     My misgiving, which I haven't thought out in detail, is that use of
header extensions in IPv6 opens a bunch of security issues.  The
security part of the ID is pretty blithe.
     The geo datum is not specified.  At the ID stage that's hardly
fatal but needs to get in eventually.
     The geo work should be followed by the header compression work in
6lowpan -- lots of bits means lots of spectrum use and lots of power
(e.g. battery power) so you want to conserve.

But do you want this content data at layer 3?  Operational
requirement...

RFC6953 (PAWS) has just been read out by IETF.  PAWS uses layer 7 geo
encoding (and specified WGS84).  Also worth reading through altho the
geo here is used for a different purpose.

b

On Thu, 2014-11-13 at 05:18 +0100, Alexandru Petrescu wrote:
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 13 Nov 2014 21:35:17 +0100

> security part of the ID is pretty blithe.

I agree.  A colleague IETFer also told me the privacy risk may be there.

I wonder whether the Destinations Options header of IPv6 could be 
covered by the encryption part of an ESP (Encapsulating Security Payload 
of IPsec), or if otherwise DO must always travel in clear.

> fatal but needs to get in eventually.

I agree.  This is a good remark.

> But do you want this content data at layer 3?  Operational

This is a good question.  Many remarks in geonet/its were about the fact 
that sending geo-position data should happen at app layer, not 
elsewhere.  An official report tells a country's vehicular comm 
standards should not consider geo-position as strongly as another 
country's similar standard - naming the wrong situation at network layer 
as a reason.

On another hand, many standards don't really feature application layers 
distinct from network layers.  If all applications run in the network 
layer, is it still non-recommended to put geo-position in there?

> geo here is used for a different purpose.

Ok, will look at this spectrum related document.

The application seems to be different for PAWS (spectrum).

HEre, if I understand correctly, IPv6 GEO may be useful for emergency 
kinds of apps.  In that sense, one would like _any_ packet out of a node 
to tell its position, not necessarily the packets issues by one 
particular application.

I.e. one may wonder what happens if some application in the computer 
crashes - will the control center loose computer's position?  because 
the kernel may still echo requests from the control center, piggybacked 
with DO GEO IPv6.

Alex

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 13 Nov 2014 14:39:39 -0700

Alex -

I would look at the DHCP Location extension to see how the datum is 
specified. Also, if more than one datum (WGS 84) is required then I would 
consider using the appropriate EPSG codes, which the DHCP Location RFC also 
uses. To whit:

Datum Registry

   IANA has created and now maintains the Datum registry following the
   guidelines below.

   The registry consists of three values: Datum, Description, and
   Reference.  These are described below.

   Datum: An integer, refers to the value used in the DHCPv4 GeoConf and
      the DHCPv4 and DHCPv6 GeoLoc options described in this document.
      Value 0 is Reserved.  Values 1 - 3 are assigned.  Values 4 - 7 are
      Unassigned [RFC5226].

   Description: The description of the altitude described by this code.

   Reference: The reference to the document that describes the Datum
      code.  This reference MUST include specification of both the
      horizontal and vertical datum, and MUST define the way that the
      34-bit values and the respective 6-bit uncertainties are
      interpreted.

   Initial values are given below; new assignments are to be made
   following the "Standards Action" policies [RFC5226].

      +------+----------------------------------------+--------------+
      |  #   |  Description                           |  Reference   |
      +------+----------------------------------------+--------------+
      |  0   | Reserved                               |  RFC 6225    |
      +------+----------------------------------------+--------------+
      |  1   | Vertical datum WGS 84 defined by EPSG  |  RFC 6225    |
      |      | CRS Code 4327                          |              |
      +------+----------------------------------------+--------------+
      |  2   | Vertical datum NAD83 defined by EPSG   |  RFC 6225    |
      |      | CRS Code 4269 with North American      |              |
      |      | Vertical Datum of 1988 (NAVD88)        |              |
      +------+----------------------------------------+--------------+
      |  3   | Vertical datum NAD83 defined by EPSG   |  RFC 6225    |
      |      | CRS Code 4269 with Mean Lower Low Water|              |
      |      | (MLLW) as associated vertical datum    |              |
      +------+----------------------------------------+--------------+
      | 4-7  | Unassigned                             |              |
      +------+----------------------------------------+--------------+

>From https://tools.ietf.org/html/rfc6225#page-18

Cheers

Carl

-----Original Message----- 
From: Alexandru Petrescu
Sent: Thursday, November 13, 2014 1:35 PM
To: Rex Buddenberg
Cc: [email-masked]
Subject: Re: [geonet/its] Presentation of draft about geolocation in IPv6 
headers - 6MAN Working Group

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Nov 2014 12:12:58 +0100

Richard,

Le 15/11/2014 01:33, Richard Roy a écrit :
> My initial comment on the draft is that the concept of a destination
> options field is inappropriate and opens security holes and creates a
> possible attack vector needlessly.

But (1) a DO header must not be examined by intermediary routers, by
definition, and (2) if the end node feels at risk, the Destinations
Options (DO) header may be put after an Encapsulation Security Payload
(ESP) header, and as such be hidden from unwanted scrutiny.

> The destination of a packet is by definition a place where the ADU is
> parsed/consumed. Any information intended only for the destination
> should be carried ONLY in the ADU, not in any lower layer PDU.
> Hence, the concept of "destination options" at a lower layer (i.e.
> the network layer) amounts to a layer violation.

YEs, layer violation may be what can happen.

But in more detail, there are already many details in the networking 
layer that may differentiate it from layer violation - most extension 
headers carry info which may qualify as app by some, but are qualified 
as networking by others.

Another indication that Geo-information may be fit in the networking 
layer is in the popular net analyzer Wireshark showing Source GeoIP and 
Destination GeoIP in all packets displayed, even if unknown.

> The ONLY reason to carry GEO information in a layer 3 header is that
> there are layer 3 processes/functions that require or will make use
> of that information.  If the information is only useful at the
> destination, then the information belongs in a layer 4 header or
> higher up the stack.

I agree.

But the location information itselfy can qualify as more app-layer or 
more 'net'-layer.  I live on the 4th floor - that is the app-layer of 
saying location; I live at 2/49/WGS48 is more of a 'net'-layer.

Second, the app layers are less reliable than the 'net'-layer.  An UDP 
userspace application sending the GPS coordinates can crash at any time 
and as such track is lost of some object.  On another hand, same data 
sent by the IP stack in the kernel as much less chances to crash - the 
kernel is much more reliable and less latency than the userspace space 
apps.  It can be made even real time (rely on tangible hw features), 
whereas apps are hard to make real time.

Third, other agreed non-IP networking layers already exchange 
geo-location information - are these net layers or app layers?

> Since the document claims that "This document seeks to specify a
> method for including the geolocation data in the IPv6 Destination
> Options header", it clearly seems to be focused on peer-to-peer
> exchange of GEO information. This is more safely accomplished at
> layers above the network layer.  Note that the ONLY example given of
> an application involving layer 3 functionality was
>
> "Convergence of dynamic routing protocols in a wide variety of mobile
> networks can benefit greatly from knowledge of the geographical
> locations of prospective neighbors.  This information is best
> conveyed in the headers of IPv6 packets used for routing protocol
> control message exchanges."

I agree with this draft's point.  The location information is a good 
hint for routing convergence.  When most core links have similar speeds, 
better connect to the closer router.  Router location is also good for a 
tie breaker when two destination have equal costs.

> All the others involved sending source location to destination(s) and
> that's NOT a layer 3 problem.
>
> Finally, the issue of coordinate systems was not addressed properly.
> It's implied by the description in the text that WGS84 is used,
> however, this system is subject to update and change.  IF the IETF is
> going to include GEO info in it's headers, there must be a field with
> sufficient size to encode the coordinate system that is being used
> and which version thereof.

I agree.

> Furthermore, the issue of uncertainly (estimate error covariance
> really) was not addressed.  All GEO locations are "estimates" and are
> realizations of a vector random process that has an associated MD
> PDF.  The ability to also communicate other than jus the zeroth order
> moment (i.e., the mean) is often important!

I agree.

Alex

>
> RR
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Wednesday, November 12,
>> 2014 8:19 PM To: [email-masked] Subject: [geonet/its] Presentation of
>> draft about geolocation in IPv6 headers - 6MAN Working Group
>>
>> Hello,
>>
>> Friday morning there will be a presentation about using
>> geolocation information in IPv6 headers, in the 6man Working
>> Group.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Nov 2014 12:30:30 +0100

Carl, colleagues,

Thank you for the remarks on this draft.

Much of the argumentation was on the privacy aspects and 
appropriatedness at the networking layer, with pros and cons.

The conclusion is that there should be more discussion on this.

The audiolog of the presentation in 6MAN WG on Nov. 14th, and the 
discussion are online at:
http://www.ietf.org/audio/ietf91/
ietf91-coral3-20141114-0900-am1.mp3
in the zone from 1hour 24min 35sec until 1h 47m 34s.

Slides at:
http://www.ietf.org/proceedings/91/slides/slides-91-6man-8.pdf

Video of entire session at:
http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF91_6MAN&chapter=chapter_0

Alex

Le 13/11/2014 22:39, Carl Reed a écrit :
> specified. Also, if more than one datum (WGS 84) is required then I
> would consider using the appropriate EPSG codes, which the DHCP Location
> RFC also uses. To whit:
>
> Datum Registry
>
>
> Subject: Re: [geonet/its] Presentation of draft about geolocation in
> IPv6 headers - 6MAN Working Group
>

---

From: "Carl Reed" <[email-masked]>
Date: Mon, 24 Nov 2014 09:47:06 -0700

Thanks, Alex -

I reviewed the slides. Very informative.

In terms of the aviation community and their requirements, the OGC has been 
working with the FAA, Eurocontrol, SESAR and a number of related 
organizations on the geospatial elements in a number of standards that are 
part of the NextGen architecture. These include FIXM (Flight Information), 
WXXM (weather), and AIXM (aeronautical information). A good overview and can 
be found here:

https://www.fbcinc.com/e/ATIEC/presentations/Tuesday/Percivall_-_08-26_120_-_OGC_Testbed_10_Aviatio.pdf

These geo-related standards activities are using the OGC/ISO Geography 
Markup Language (GML). The geometry elements in in GML are based on the 
abstract model defined in ISO 19107: Spatial Schema. As such, the aviation 
community use of GML is consistent with the IETF geodetic location object as 
defined by the GeoPriv WG activity as well as the geo extension for DHCP.

My point is that consistency across the standards stack in how geo is 
specified would enhance interoperability and ease of implementation.

I need to check the internet drafts referenced in the presentation.

Thanks!

Carl

-----Original Message----- 
From: Alexandru Petrescu
Sent: Monday, November 24, 2014 4:30 AM
To: Carl Reed ; Rex Buddenberg ; Templin, Fred L
Cc: [email-masked]
Subject: Re: [geonet/its] Results - presentation of draft about geolocation 
in IPv6 headers - 6MAN Working Group

Carl, colleagues,

Slides at:

Alex

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 24 Nov 2014 10:36:35 -0800

Alex and Roy,

You've got most of the security issues here, but we can organize the
thinking better.  Reasoning through the security -- specifically the
scope of security -- can clarify your requirements questions enormously.

> > destination, then the information belongs in a layer 4 header or

You're discussing layer 3 vs layer 7 security.  This is right, but it
may make more sense if we fill in the rest of the matrix:

2.  Layer 1 and 2 security measures (e.g. anything sounding like 'wifi
security') means security measures applied to ethernet headers and
payloads.  Because the layer 2 header is discarded before the first
router, the scope of security is single segment.  No farther.  No matter
how perfect your layer 2 security may be, it's scope is only one
segment.

3.  Layer 3 security is applied to datagrams.  This is what the ID in
6MAN is doing.  The scope of security is enclave as in VPN.  (Enclaves
do not include end systems).  The chief payoff in layer 3 security is
that you can mix multiple wide area networking needs into a single
infrastructure -- each community can have an enclave to itself.  
    
4-5.  Layer 4 and 5 security secures connections.  The primary example
is SSL (aka TLS).  Commonly used for e-commerce and commonly worked
around by Bad Guys because they attack places outside of the security
scope.  Layer 4 security solutions are applied at the I/O outer layer of
the operating system (at the network socket).  Similarly, the security
protection is removed at the network socket on arrival at destination,
thereby leaving the data unprotected within the OS.  

6-7.  Protection applied at layer 6-7 is only removed by an application
(or the library routines that an application calls).  Layer 6-7
protection is generically different than lower layer protections in that
it protects data, not infrastructure.  Layer 6-7 protection is
end-to-end -- from end system to end system, wholly agnostic about the
networking infrastructure.   Because it protects the data, layer 6-7
protection can protect data at rest (e.g. on a flash or disk drive) just
as easily as over the internetwork.  So it's not only end-system to
end-system, but _through_ end systems as well, partially protecting the
data against possible malware in an end system.
     E-mail, with S/MIME protections, is the most ubiquitous example of
layer 6-7 protections.

This exchange is correct; it makes, IMHO, even better sense when you
> > that's NOT a layer 3 problem.

Geographic information is exchanged in organized form by several
> geo-location information - are these net layers or app layers?

SNMP, for example, contains a location variable in the MIB.  It's only
defined as a string right now but it's a space where an administrator
can say 'this gadget is installed in the 4th floor wiring closet'.  You
could certainly encode a Lat/Lon/Alt chunk of data in the space.  SNMP
is an application -- layer 7.  So the scope of the SNNP (v3) security
measures is indeed end-to-end.  
    PAWS, which I've mentioned before on [its] also is an application.
Layer 6-7.  It's Lat/Lon/Alt information is therefore at app layer.  The
security considerations in PAWS are exclusively targeted at protecting
the data.

You've commented that wiretapping layer 3 geo information for layer 7
application purposes would be a layer violation.  That is most certainly
correct.  But what are the consequences of a layer violation?  
  1.  The longer term consequence is that this disrupts the organization
of the internet with downstream negatives regarding interoperability and
flexibility.  While true, this is a hard argument to sell to a guy with
a screwdriver in his hand.  
  2.  The more telling argument is the security scope one.  Layer
violations provide vectors for penetrating security.  Because the layer
violation always increases the scope of vulnerability.

Help??

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 24 Nov 2014 17:07:09 +0000

Hi, thank you for the discussion on this topic. I will join the 'its' list to be sure we
can track the rest of the activity.

We are open to specific comments on draft-skeen-6man-ipv6geo. We would
like to be sure that anything we specify is consistent with industry standards.

The document pointers are appreciated, and we will take a look.

Thanks - Fred
[email-masked]

> From: Carl Reed [mailto:[email-masked]]
> Sent: Monday, November 24, 2014 8:47 AM
> To: Alexandru Petrescu; Rex Buddenberg; Templin, Fred L; George Percivall
> Cc: [email-masked]
> Subject: Re: [geonet/its] Results - presentation of draft about geolocation in IPv6 headers - 6MAN Working Group
> 
> Thanks, Alex -
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Nov 2014 19:04:00 +0100

Le 24/11/2014 19:36, Rex Buddenberg a écrit :
[...]
> infrastructure -- each community can have an enclave to itself.

Right.

The protection afforded by ESP and AH headers to the DO header
(containing geo coordinates) is as high, flexible and measured as any
protection at layers 4 and 5 (SSL).

Whereas one _may_ worry about the privacy risks induced by the IP source
address being always in-clear in the base header, the same worry does
not apply to something that is in the DO header.

This is why I do not understand the security worries for comments of 
this draft.

[...]

> Layer 6-7 protection is end-to-end -- from end system to end system,

And Layer 3 security is also end-system to end-system.

> wholly agnostic about the networking infrastructure.   Because it
> protects the data, layer 6-7 protection can protect data at rest
> (e.g. on a flash or disk drive) just as easily as over the
> internetwork.  So it's not only end-system to end-system, but
> _through_ end systems as well, partially protecting the data against
> possible malware in an end system. E-mail, with S/MIME protections,
> is the most ubiquitous example of layer 6-7 protections.
>
>

>> I agree with this draft's point.  The location information is a
>> good hint for routing convergence.  When most core links have
>> similar speeds, better connect to the closer router.  Router
>> location is also good for a tie breaker when two destination have
>> equal costs.
>>
>>> All the others involved sending source location to
>>> destination(s)
> and
> SNMP, for example, contains a location variable in the MIB.  It's
> only defined as a string right now but it's a space where an
> administrator can say 'this gadget is installed in the 4th floor
> wiring closet'.  You could certainly encode a Lat/Lon/Alt chunk of
> data in the space.  SNMP is an application -- layer 7.  So the scope
> of the SNNP (v3) security measures is indeed end-to-end. PAWS, which
> I've mentioned before on [its] also is an application. Layer 6-7.
> It's Lat/Lon/Alt information is therefore at app layer.

I think there are different uses of Lat/Lon/Alt information that need 
different placement in layers.

Browsing webpage to see an object location is typical example of putting 
coordinates in app layer.  It is good for certain uses like fleet 
management.

But, there are some cases where this app-layer geo-localisation is not 
enough, or sometimes plain wrong - 'inaccurate' would say some.  It is 
especially wrong when associations between the IP address and any form 
of 'localization'.  This is immediately obvious when trying any of the 
following:

- type 'where am I' in a browser to be told the other side of the
   Earth.
- VPN into a gateway to escape local rules to get access to content
   (youtube content not available in your country).
- take a long-distance train or plane and be told you're still in the
   country of origin.

[...]

> application purposes would be a layer violation.  That is most
> certainly correct.  But what are the consequences of a layer
> violation? 1.  The longer term consequence is that this disrupts the
> organization of the internet with downstream negatives regarding
> interoperability and flexibility.  While true, this is a hard
> argument to sell to a guy with a screwdriver in his hand. 2.  The
> more telling argument is the security scope one.  Layer violations
> provide vectors for penetrating security.  Because the layer

But we have IP layer security which works fine.  I dont understand where 
would be the risks?  Geo-coordinates in the IP layer would be protected 
by IP layer security, no violation, no new risk.

Alex

>>> My initial comment on the draft is that the concept of a
>>> destination options field is inappropriate and opens security
>>> holes and creates a possible attack vector needlessly.
>>
>> But (1) a DO header must not be examined by intermediary routers,
>> by definition, and (2) if the end node feels at risk, the
>> Destinations Options (DO) header may be put after an Encapsulation
>> Security Payload (ESP) header, and as such be hidden from unwanted
>> scrutiny.
>>
>>> The destination of a packet is by definition a place where the
>>> ADU is parsed/consumed. Any information intended only for the
>>> destination should be carried ONLY in the ADU, not in any lower
>>> layer PDU. Hence, the concept of "destination options" at a
>>> lower layer (i.e. the network layer) amounts to a layer
>>> violation.
>>
>> But in more detail, there are already many details in the
>> networking layer that may differentiate it from layer violation -
>> most extension headers carry info which may qualify as app by
>> some, but are qualified as networking by others.
>>
>> Another indication that Geo-information may be fit in the
>> networking layer is in the popular net analyzer Wireshark showing
>> Source GeoIP and Destination GeoIP in all packets displayed, even
>> if unknown.
>>
>>> The ONLY reason to carry GEO information in a layer 3 header is
>>> that there are layer 3 processes/functions that require or will
>>> make use of that information.  If the information is only useful
>>> at the destination, then the information belongs in a layer 4
>>> header or higher up the stack.
>>
>> I agree.
>>
>> But the location information itselfy can qualify as more app-layer
>> or more 'net'-layer.  I live on the 4th floor - that is the
>> app-layer of saying location; I live at 2/49/WGS48 is more of a
>> 'net'-layer.
>>
>> Second, the app layers are less reliable than the 'net'-layer.  An
>> UDP userspace application sending the GPS coordinates can crash at
>> any time and as such track is lost of some object.  On another
>> hand, same data sent by the IP stack in the kernel as much less
>> chances to crash - the kernel is much more reliable and less
>> latency than the userspace space apps.  It can be made even real
>> time (rely on tangible hw features), whereas apps are hard to make
>> real time.
>
>>>  method for including the geolocation data in the IPv6
>>> Destination Options header", it clearly seems to be focused on
>>> peer-to-peer exchange of GEO information. This is more safely
>>> accomplished at layers above the network layer.  Note that the
>>> ONLY example given of an application involving layer 3
>>> functionality was
>>>
>>> "Convergence of dynamic routing protocols in a wide variety of
>>> mobile networks can benefit greatly from knowledge of the
>>> geographical locations of prospective neighbors.  This
>>> information is best conveyed in the headers of IPv6 packets used
>>> for routing protocol control message exchanges."
>>
>> I agree with this draft's point.  The location information is a
>> good hint for routing convergence.  When most core links have
>> similar speeds, better connect to the closer router.  Router
>> location is also good for a tie breaker when two destination have
>> equal costs.
>>
>>> All the others involved sending source location to
>>> destination(s) and that's NOT a layer 3 problem.
>>>
>>> Finally, the issue of coordinate systems was not addressed
>>> properly. It's implied by the description in the text that WGS84
>>> is used, however, this system is subject to update and change. IF
>>> the IETF is going to include GEO info in it's headers, there must
>>> be a field with sufficient size to encode the coordinate system
>>> that is being used and which version thereof.
>>
>> I agree.
>>
>>>  really) was not addressed.  All GEO locations are "estimates"
>>> and are realizations of a vector random process that has an
>>> associated MD PDF.  The ability to also communicate other than
>>> jus the zeroth order moment (i.e., the mean) is often important!
>>
>> I agree.
>>
>> Alex
>>
>>>
>>> RR
>>>
>>>> [mailto:[email-masked]] Sent: Wednesday,
>>>> November 12, 2014 8:19 PM To: [email-masked] Subject:
>>>> [geonet/its] Presentation of draft about geolocation in IPv6
>>>> The draft is
>>>> http://tools.ietf.org/html/draft-skeen-6man-ipv6geo
>>>>
>> _______________________________________________ its mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>
>
>

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 26 Nov 2014 10:30:37 -0800

> And Layer 3 security is also end-system to end-system.

No no no, not true.

Layer 3 security covers a network enclave.  From the point where the IP
datagram is encrypted and inserted into a wrapper datagram.  
    In classical VPNs, this was done by a specialized box.  So you had a
red LAN outboard of the box.  DoD boxes that do this were called
TACLANEs.  You can push the enclave toward the end system by putting the
VPN encapsulation function in the I/O services of the end system
operating system but that's not a topological shift -- the data is still
en claire outboard of the VPN function (including all of the end
system).  
     To expand the scope of security, you have to move to higher layers.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Nov 2014 11:24:41 +0100

>       To expand the scope of security, you have to move to higher layers.

I agree considering VPN-on-gateway-and-client to not be end-to-end 
security.  Because the Gateway encaps/decaps and forwards out of it -- a 
box in the middle.  As when accessing an enterprise network from a 
remote location.

On another hand IPsec is not necessarily VPN.  IPsec can be executed on 
a client and a server, in the same manner as when using https for 
e-commerce or banking.  In that sense, it happens on each end, no 
intermediary boxes.  There is end-to-end IPsec, for example, between a 
Mobile Host and its Home Agent.  A ping can be protected by IPsec as well.

Another difference is that 'VPN' includes a set of message exchanges to 
establish keys in a dynamic manner and then use IPsec.  IPsec is just 
message formats, and a bit of local crypto.

Alex

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 27 Nov 2014 11:03:42 -0800

Still not getting it, Alex.

On Thu, 2014-11-27 at 11:24 +0100, Alexandru Petrescu wrote:
> On another hand IPsec is not necessarily VPN.

Yes it is.  The term IPsec is associated with IPv6 and the mechanism is
slightly different than in IPv4.  But the terms tunneling,
encapsulation, VPN and IPSec mean more or less the same thing.

>   IPsec can be executed on 
> e-commerce or banking. 

This is correct.  (https is the implementation of Secure Sockets Layer
or, renamed, Transport Layer Security.  The difference between TLS and
VPN is that a VPN protects and enclave and TLS protects a connection.
Both, of course, can be used.  But neither are end to end as both can
terminate no later than at the I/O socket of each end system.

>  In that sense, it happens on each end, no 
> Mobile Host and its Home Agent.

No there is not.  The scope of security is from the IPSec encypher to
the IPSec decypher which is always in the networking socket of the
operating system.  So the data has no protection from IPSec (or IPv4
VPN) within the OSs.

>   A ping can be protected by IPsec as well.

True.  A ping is simply an ICMP echo request which fits inside a
datagram.  Datagrams are what VPNs protect.  (The diff is that in IPv4,
a separate RFC defines Internet Control Message Protocol; in IPv6 this
stuff is rolled into the IPv6 documentation rather than as a separate
RFC.)
> establish keys in a dynamic manner and then use IPsec.

Whatever the layer that protection is implemented, there has to be some
peer-peer agreement on keys.  There are, of course, multiple ways to
exchange keys, both in and out of band.  But this is not relevant to
understanding the scope of security.

>   IPsec is just 

Well, no.  IPv4 tunneling grew up outside of the standardization
process.  Which meant that there were (and are) a variety of different
VPN systems (usually brand specific).  These are all _compatible_
(datagrams are datagrams and they all get handled by routers the same
way) meaning you can accommodate an indefinite number of VPNs over a
routed communications infrastructure.  But they are not _interoperable_
without some agreement on elements (especially key control and
distribution).  When the IPng working group reworked the system, they
absorbed the lessons of IPv4 VPNs and included IPSec (IP security -- it
tells you the scope right in the title) in he IPv6 RFCs.  

The point to remember is that neither IPsec (layer 3) or TLS (layer 4-5)
provide any protection within the operating systems of end systems.
(Gateways included).

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Nov 2014 14:59:28 +0100

[...]
> understanding the scope of security.

Based on this argumentation, can we draw that wherever one's 
geo-position data is placed (at the IP layer in a Destination Options 
header, or at the app layer in a https payload), there are several means 
such as VPN or IPsec to protect it against undesirable inspection - to 
respect one's privacy.

Am I correct?

Alex

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 28 Nov 2014 09:45:37 -0800

> such as VPN or IPsec to protect it against undesirable inspection - to 

You could put a chunk of metadata in a header at layers 2,3,4 and 7.
(Implementation is harder in some than others, but you could).

The problem, as I've tried to illustrate, is that you need to match the
availability of the data to the scope of the security.

If you embed the geo data at layers 2, 3, or 4 then you commit a layer
violation (which equals a security compromise vector) if you want the
data to be visible at layer 7.  If you want the data to be (securely)
visible at layer 7 then you need to put it in a layer 7 vehicle, not a
layer 3 one.  If, on the other hand, you want the geo data to be visible
at layer 3 (for routing decisions, presumably) then the approach of
using IP datagram header extensions is a feasible one.  This is why I
was asking what application you're after.