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

[Alexandru Petrescu <[e-mail]>]

Le 24/11/2014 19:36, Rex Buddenberg a écrit :
[...]
> 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.

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.
>
>
> This exchange is correct; it makes, IMHO, even better sense when you
>  apply the scope of security reasoning:

>> 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.
>
>
> Geographic information is exchanged in organized form by several
> internet applications:
>> Third, other agreed non-IP networking layers already exchange
>> 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.

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.

[...]

> 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.

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



>
>
>
> Help??
>
>
>
>
> On Mon, 2014-11-24 at 12:12 +0100, Alexandru Petrescu wrote:
>> 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.
>
>>> 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:[e-mail]] Sent: Wednesday,
>>>> November 12, 2014 8:19 PM To: [e-mail] 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.
>>>> 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
>>>>
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________ its mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/its
>
>
>
>