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

[Rex Buddenberg <[e-mail]>]

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.


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

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




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