Subject: [6lo] New I-D draft-delcarpio-6lo-wlanah-00.txt

From: Felipe Del Carpio <[email-masked]>
Date: Wed, 17 Jun 2015 09:02:30 +0000

Dear all,

We present how 6LoWPAN can be used to efficiently transport IPv6 over 802.11ah, this is a first version.

Some of our concerns in study:

1) At the end of section 6, this text was written
 " For non-link-local addresses a 64-bit IID MAY be formed by utilizing
     the 48-bit MAC device address.  Random IID can be generated for 6LN
     using alternative methods such as [I-D.ietf-6man-default-iids]."
     Is this sufficient?

2) How to use 6CO option along with Router advertisements for compression context?

3) Section 8

We would appreciate your comments and suggestion on this draft.

Thank you very much in advance,

Felipe, Ines and Roberto

--------------------------------------------------------

A new version of I-D, draft-delcarpio-6lo-wlanah-00.txt has been successfully submitted by Maria Ines Robles and posted to the IETF repository.

Name:		draft-delcarpio-6lo-wlanah
Revision:	00
Title:		IPv6 over 802.11ah
Document date:	2015-06-17
Group:		Individual Submission
Pages:		15
URL:https://www.ietf.org/internet-drafts/draft-delcarpio-6lo-wlanah-00.txt
Status:https://datatracker.ietf.org/doc/draft-delcarpio-6lo-wlanah/
Htmlized:https://tools.ietf.org/html/draft-delcarpio-6lo-wlanah-00

Abstract:
    IEEE 802.11 is an established Wireless LAN (WLAN) technology which
    provides radio connectivity to a wide range of devices.  The IEEE
    802.11ah amendment defines a WLAN system operating at sub 1 GHz
    license-exempt bands designed to operate with low-rate/low-power
    consumption.  This amendment supports large number of stations and
    extends the radio coverage to several hundreds of meters.  This
    document describes how IPv6 is transported over 802.11ah using
    6LoWPAN techniques.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Jun 2015 19:04:58 +0200

Hi,

> 802.11ah, this is a first version.

Will subGhz 802.11ah be the same in each country?  Or not?

We know for example that 802.11a is not deployed, not marketed, and not 
important at all in the country where I live; yet it is important in 
other countries.

Is 802.11ah specific to a particular country?  We know that some 
802.11"letter" works in only one particular country.

> 1) At the end of section 6, this text was written " For
> non-link-local addresses a 64-bit IID MAY be formed by utilizing the
> 48-bit MAC device address.  Random IID can be generated for 6LN using
> alternative methods such as [I-D.ietf-6man-default-iids]." Is this
> sufficient?

I think that "MAY" is good - it is good to refer to any I-D
or RFC in this privacy space, to make the tracking based on MAC
addresses  more difficult to attackers.  The default-iids draft is good,
and there is also RFC7217.

Further along the lines of a "MAY" I would like to suggest that not only
utilisation of MAC be a "MAY" but also the 64bit length of an IID be a
MAY, let me explain why.

I think link-local addresses are not necessarily an issue with the /64
bit limit, because their prefix is a constant fe80.

But the globally unique, and ULAs, addresses may have some issue if
auto-configured with SLAAC.

Will an 802.11ah interface be built-in into a cellular phone, 
smartphone?  Because 802.11ah energy savings may be very relevant for 
cellular phones more than for any other routers.

But cellular phones (smartphones) are not able to run 
statelessautoconf/Ethernet on the 802.11ah interface,
because the interface ID is 64bit length.

In that case, it may be possible to use an Interface ID of length 48bit
(the MAC address on 802.11ah).

> 2) How to use 6CO option along with Router advertisements for

The section 8 is about HC.

I would like to ask whether HC means to eliminate the IPv6 Base Header
and if yes then the subsequent question is whether we can still consider
this to be "IPv6 over..." when there is no IPv6.

Because RFC2460 says that the IPv6 Base Header is mandatory.

> We would appreciate your comments and suggestion on this draft.

I would to like to comment to ask whether you have packet dumps of
IPv6/802.11ah?  And wireshark dissectors?

About the security considerations section:
Is e2e IPsec security still afforded even though an intermediary router 
must hold keys for eliminated/reinserted IPv6 base header?

Thanks,

Alex

> A new version of I-D, draft-delcarpio-6lo-wlanah-00.txt has been
> successfully submitted by Maria Ines Robles and posted to the IETF
> repository.
>
> Name:		draft-delcarpio-6lo-wlanah Revision:	00 Title:		IPv6 over
> 802.11ah Document date:	2015-06-17 Group:		Individual Submission
> Pages:		15
> Abstract: IEEE 802.11 is an established Wireless LAN (WLAN)
> technology which provides radio connectivity to a wide range of
> devices.  The IEEE 802.11ah amendment defines a WLAN system operating
> at sub 1 GHz license-exempt bands designed to operate with
> low-rate/low-power consumption.  This amendment supports large number
> of stations and extends the radio coverage to several hundreds of
> meters.  This document describes how IPv6 is transported over
> 802.11ah using 6LoWPAN techniques.
>
> _______________________________________________ 6lo mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/6lo
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Jun 2015 20:01:50 +0200

> Because RFC2460 says that the IPv6 Base Header is mandatory.

Alex,

you are trying to make this point again and again.

Indeed, header compression is a concept that is usually not taught at
universities.  My standard talk about header compression starts with
pointing out that there isn't even a Wikipedia page about this subject!

However, as manifested in RFC 1144, there is a long tradition of using
header compression in link layer mappings for the Internet.  The fact
that you cannot make out the IPv6 header when looking at the bytes on
the air in a 6LoWPAN doesn't mean it is not being sent.  It is just
encoded in an efficient way.  (This is different from the confused idea
of "header stripping", where the IP header actually is not made
available to the recipient in a way such that it can be decoded.)

I do think your input to this WG is useful.  It would probably have more
impact if you could stop tilting at this particular windmill.

Grüße, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jun 2015 11:26:46 +0200

Carsten,

Le 17/06/2015 20:01, Carsten Bormann a écrit :
>> I would like to ask whether HC means to eliminate the IPv6 Base
>> Header and if yes then the subsequent question is whether we can
>> still consider this to be "IPv6 over..." when there is no IPv6.
>>

Ok, let me summarize  instead of turning in circles:

I would like to request a modification of that Internet Draft - please 
add a statement saying that the IPv6 Base Header is mandatory, in clear, 
in network byte order.

> pointing out that there isn't even a Wikipedia page about this

I am not sure a wikipedia page on Header Compression is necessarily good 
for HC altogether.

If one wants to study Header Compression there is plethora of 
authoritative information in the Information Theory section of your 
University Library.

> However, as manifested in RFC 1144, there is a long tradition of
> using header compression in link layer mappings for the Internet.

I think RFC1144 is no longer in use.  It should be declared Historic.

ROHC (RObust Header Compression RFC6846) is not applied to IP layer, as 
far as I know, but to upper layers.  Despite being touted decades ago as 
absolutely necessary for WiFi and cellular, what we use today on these 
links is pure IP.

Am I missing something?

> The fact that you cannot make out the IPv6 header when looking at
> the bytes on the air in a 6LoWPAN doesn't mean it is not being sent.
> It is just encoded in an efficient way.

What is meant by 'encoded in an efficient way'?

If what is meant is substituting a shorter header for the IPv6 Base 
Header then that's obviously not IPv6.  Because the IPv6 Base Header 
must be transmitted in full in clear in network byte-order.  The only 
modifs the network can make to it is decrementing the Hop Limit.

To further understand what is meant by 'encoded in an efficient way' I 
looked at the wireshark dumps using 6lowpan headers on 15.4 at:
http://svn.tools.ietf.org/svn/wg/6lowpan/packets/
(e.g. dis_option7.pcap)
They exhibit that there is a 15.4 header, a 6lowpan header _and_ an IPv6 
Base Header.  Efficiency couldnt mean to insert an additional header:

Ethernet II header                    Ethernet II header
IEEE 802.15.4 Data header             IEEE 802.15.4 Data header
6LoWPAN header                vs.     IPv6 Base Header
IPv6 Base Header                      ICMPv6 header
ICMPv6 header

This is why I dont understand what is meant by 'encoded in an efficient 
way'.

> (This is different from the confused idea of "header stripping",
> where the IP header actually is not made available to the recipient
> in a way such that it can be decoded.)

Well, please clarify: is the IPv6 Base Header present or not?  If it's 
not then it's stripped, right?

Alex

---

From: Felipe Del Carpio <[email-masked]>
Date: Thu, 18 Jun 2015 10:28:17 +0000

Dear Alexandru, 

Thank you very much for your comments, please find answers inline in [FDC]. 

Best regards, 
Felipe

> -----Original Message-----
> From: 6lo [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Wednesday, June 17, 2015 8:05 PM
> To: [email-masked]
> Subject: Re: [6lo] New I-D draft-delcarpio-6lo-wlanah-00.txt
> 
> Hi,
> 
> important at all in the country where I live; yet it is important in other countries.
> 
> Is 802.11ah specific to a particular country?  We know that some 802.11"letter"
> works in only one particular country.
> 

[FDC] 802.11 standards work on ISM bands and indeed different regions in the world have defined ISM bands in slightly different frequencies and have imposed different regulations for each ISM band. 802.11ah is no exception to this rule, it will use an ISM band below 1Ghz. The exact frequency depends on the region. In a reference document from IEEE (https://mentor.ieee.org/802.11/dcn/11/11-11-1296-03-00ah-potential-channelization-for-11ah.pptx) you can see potential channelization for different regions.

> > 1) At the end of section 6, this text was written " For non-link-local
> > addresses a 64-bit IID MAY be formed by utilizing the 48-bit MAC
> > device address.  Random IID can be generated for 6LN using alternative
> > methods such as [I-D.ietf-6man-default-iids]." Is this sufficient?
> 
> I think that "MAY" is good - it is good to refer to any I-D or RFC in this privacy
> space, to make the tracking based on MAC addresses  more difficult to
> attackers.  The default-iids draft is good, and there is also RFC7217.
> 
> utilisation of MAC be a "MAY" but also the 64bit length of an IID be a MAY, let
> me explain why.
> 
> I think link-local addresses are not necessarily an issue with the /64 bit limit,
> because their prefix is a constant fe80.
> 
> But the globally unique, and ULAs, addresses may have some issue if auto-
> configured with SLAAC.
> 
> Will an 802.11ah interface be built-in into a cellular phone, smartphone?
> Because 802.11ah energy savings may be very relevant for cellular phones more
> than for any other routers.

[FDC] Indeed, the energy saving mechanisms are useful for battery operated devices like a Smartphone. Also connected sensors such as temperature sensors could be connected to internet through an 802.11ah link.

> statelessautoconf/Ethernet on the 802.11ah interface, because the interface ID
> is 64bit length.
> 
> In that case, it may be possible to use an Interface ID of length 48bit (the MAC
> address on 802.11ah).
> 

[FDC] The 48bits MAC address can be converted to a 64bit format by standard means. I think if there is a need a Smartphone can implement all necessary procedures to work this out.

> I would like to ask whether HC means to eliminate the IPv6 Base Header and if
> yes then the subsequent question is whether we can still consider this to be "IPv6
> over..." when there is no IPv6.
> 

[FDC] Please note that the proposed stack include IPv6 layer, what we propose is to compress its transport using 6LoWPAN.

> IPv6/802.11ah?  And wireshark dissectors?

[FDC] As far as we know, there are no existing devices in the market that implement 802.11ah to this date.

> Is e2e IPsec security still afforded even though an intermediary router must hold
> keys for eliminated/reinserted IPv6 base header?
> 

[FDC] Please note that there is no intermediary routers in 802.11ah. However we believe that IPsec can be implemented in this kind of networks following [https://tools.ietf.org/html/draft-raza-6lowpan-ipsec-01]

> > Abstract: IEEE 802.11 is an established Wireless LAN (WLAN) technology
> > which provides radio connectivity to a wide range of devices.  The
> > IEEE 802.11ah amendment defines a WLAN system operating at sub 1 GHz
> > document describes how IPv6 is transported over 802.11ah using 6LoWPAN
> > techniques.
> >
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jun 2015 14:34:45 +0200

Dear Felipe,

Le 18/06/2015 12:28, Felipe Del Carpio a écrit :
> Best regards, Felipe
>> -----Original Message----- From: 6lo [mailto:[email-masked]]
>> On Behalf Of Alexandru Petrescu Sent: Wednesday, June 17, 2015 8:05
>> PM To: [email-masked] Subject: Re: [6lo] New I-D
>> draft-delcarpio-6lo-wlanah-00.txt
>>
>> Hi,
>>
>> We know for example that 802.11a is not deployed, not marketed, and
>> not important at all in the country where I live; yet it is
>> important in other countries.
>>
> [FDC] 802.11 standards work on ISM bands

Well, not all 802.11 are on ISM bands.  802.11p is not on an ISM band.
(5.9GHz).

> and indeed different regions in the world have defined ISM bands in
> slightly different frequencies and have imposed different regulations
> for each ISM band. 802.11ah is no exception to this rule, it will use
> an ISM band below 1Ghz. The exact frequency depends on the region. In
> a reference document from IEEE
> (https://mentor.ieee.org/802.11/dcn/11/11-11-1296-03-00ah-potential-channelization-for-11ah.pptx)

That ppt tells 863-868,6MHz for Europe.  In France that is 25mW (like 
WiFi).  It is not forbidden.  So I guess it can work.

But I dont think running at 863MHz will save any much energy, instead of 
running at 2.4GHz.

It will offer a much lower bandwidth than WiFi, for much simpler 
applications (i.e. alarm on/off, window open/close rather than video 
stream at 11ad's 1GBps at 60GHz).  And because the amount of data 
transmitted is much lower that there will be energy savings.

In that sense, I dont think there is anything to do to modify IPv6 to 
work on it.  (and yes, IPv6 must work ok on 11ah, as it works on WiFi, 
and it is worth documenting in a document).

 >>> you can see potential channelization for different regions.
>>> non-link-local addresses a 64-bit IID MAY be formed by utilizing
>>> the 48-bit MAC device address.  Random IID can be generated for
>>> 6LN using alternative methods such as
>>> [I-D.ietf-6man-default-iids]." Is this sufficient?
>>
>> I think that "MAY" is good - it is good to refer to any I-D or RFC
>> in this privacy space, to make the tracking based on MAC addresses
>> more difficult to attackers.  The default-iids draft is good, and
>> there is also RFC7217.
>>
>> Further along the lines of a "MAY" I would like to suggest that not
>> only utilisation of MAC be a "MAY" but also the 64bit length of an
>> IID be a MAY, let me explain why.
>>
>> I think link-local addresses are not necessarily an issue with the
>> /64 bit limit, because their prefix is a constant fe80.
>>
>> auto- configured with SLAAC.
>>
>> smartphone? Because 802.11ah energy savings may be very relevant
>> for cellular phones more than for any other routers.
>
> [FDC] Indeed, the energy saving mechanisms are useful for battery
> operated devices like a Smartphone. Also connected sensors such as
> temperature sensors could be connected to internet through an
> 802.11ah link.

If you agree this is for a smartphone, it would be good to note that a 
smartphone can not get a shorter-than-64 prefix from a cellular 
operator, and as such can not send an RA containing a /64 on its 11ah 
interface - it will have to send a /65 in that RA.  Because of that an 
11ah sensor connecting to the 11ah interface of the smartphone and 
forming an IID of length 64 will lead to IPv6 address of length 129. 
That can not work.

Also, an 11ah sensor would like to be able to talk using IPv6 to its 
11b-only neighbor, both one the same hotspot emitted by a smartphone 
equipped of one single interface featuring all 11b/g/n/ac/ad/ah 
characteristics.  Right?

>> statelessautoconf/Ethernet on the 802.11ah interface, because the
>> interface ID is 64bit length.
>>
>> In that case, it may be possible to use an Interface ID of length
>> 48bit (the MAC address on 802.11ah).
>>
>
> [FDC] The 48bits MAC address can be converted to a 64bit format by
> standard means. I think if there is a need a Smartphone can implement
> all necessary procedures to work this out.

Yes, there is.

What I mean is to allow the smartphone to form an IID of length 48 out 
of the 48bit MAC address.  This will allow SLAAC to form 128bit IPv6 
addresses when the RA contains a prefix of length 65.

If the RA contains a prefix of length 65 and the IID is of length 64 
then the SLAAC will form addresses of length 129.

> [FDC] Please note that the proposed stack include IPv6 layer, what we
> propose is to compress its transport using 6LoWPAN.

It is strange to hear 'transport' because for me 'transport' is above IP 
not below it.  But be it.

> that implement 802.11ah to this date.

Ok, maybe it is a good start.  Let us hope for the best.

>> About the security considerations section: Is e2e IPsec security
>> still afforded even though an intermediary router must hold keys
>> for eliminated/reinserted IPv6 base header?
>>
>
> [FDC] Please note that there is no intermediary routers in 802.11ah.

Ok.

> However we believe that IPsec can be implemented in this kind of
> networks following
> [https://tools.ietf.org/html/draft-raza-6lowpan-ipsec-01]

I will comment separately on HC and end2end security.  BAsically, if the 
IPv6 base header is eliminated and reconstructed by some intermediary 
then there is a risk of attack unless the keys are shared with some 
entity in the network - that sharing breaks e2e security: one doesnt 
want to share keys with any intermediary (MiTM) than the other end of 
the communication.

Alex

>>> successfully submitted by Maria Ines Robles and posted to the
>>> IETF repository.
>>>
>>> URL:https://www.ietf.org/internet-drafts/draft-delcarpio-6lo-wlanah-00
>>>
>>>
.txt
>>> devices.  The IEEE 802.11ah amendment defines a WLAN system
>>> operating at sub 1 GHz license-exempt bands designed to operate
>>> with low-rate/low-power consumption.  This amendment supports
>>> large number of stations and extends the radio coverage to
>>> several hundreds of meters.  This document describes how IPv6 is
>>> transported over 802.11ah using 6LoWPAN techniques.
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jun 2015 17:59:36 +0200

Dear Felipe,

[...]
> [FDC] Please note that there is no intermediary routers in 802.11ah.

Ok. I meant IPv6 routers:

  +-----------+      +-----------+        ---------      +-----------+
  |11ah device|------|IPv6 router|-------|Internet |-----|11ah device|
  +-----------+      +-----------+        ---------      +-----------+

> [https://tools.ietf.org/html/draft-raza-6lowpan-ipsec-01]

Well, that draft seems to be trying to compress IPsec headers, similarly 
to LOWPAN_IPHC substituting new headers for RFC2460 IPv6 headers.

But the LOWPAN_IPHC header is insecure, whereas the IPv6 Base Header is 
secured by IPsec.

The risk includes faking LOWPAN_IPHC headers between two 11ah devices
in the same subnet.

Waht do you think?

Further, you are saying in the draft the following:
> The security considerations defined in [RFC4944] and its update
> [RFC6282] can be assumed valid for the 802.11ah case as well.

Neither RFC6282 nor RFC4944 offer a security mechanism for the
LOWPAN_IPHC header.

> Indeed, the transmission of IPv6 over 802.11ah links meets all the
> requirements for security as for IEEE 802.15.4.

No.

The transmission of IPv6 over 802.11ah links requires that IPsec works
fine on them.  An IPv6 11ah-only device must be able to use IPsec to
protect its IPv6 communications with an IPv6 11b-only device in the same
subnet.  And an IPv6 11ah-only device must be able to use IPsec to
protect its IPv6 communications to an IPv6 11ah-only device across the
Internet.

These are the security requirements for IPv6 over 11ah.

Do you agree?

> The standard IEEE 802.11ah defines all those aspects related with
> Link Layer security.

Where?  Is a document publicly available?

Is the Link Layer security defined by IEEE 802.11ah protecting the 
LOWPAN_IPHC header?

Does IEEE 802.11ah even mention LOWPAN_IPHC?

>    As well as for other existing WiFi solutions, 802.11ah Link Layer
>    supports security mechanism such as WPA, WPS, 802.1X.

But neither of these (WPA, WPS, 802.1X) carry LOWPAN_IPHC headers as far 
as I know.  They carry IPv6 Base Headers, ethertype 0x86dd.

Alex

---

From: Felipe Del Carpio <[email-masked]>
Date: Thu, 18 Jun 2015 16:16:40 +0000

Dear Alexandru, 

Thank you very much, I appreciate your comments. Please see my answers inline with mark [FDC].

Best regards, 
Felipe

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Thursday, June 18, 2015 3:35 PM
> To: Felipe Del Carpio; [email-masked]
> Cc: Roberto Morabito; MARIA INES ROBLES
> >> -----Original Message----- From: 6lo [mailto:[email-masked]] On
> >> Behalf Of Alexandru Petrescu Sent: Wednesday, June 17, 2015 8:05 PM
> >> To: [email-masked] Subject: Re: [6lo] New I-D
> >> not important at all in the country where I live; yet it is important
> >> in other countries.
> >>

[FDC] Thanks for the comments. I haven't study much the V2V  amendment yet.
> That ppt tells 863-868,6MHz for Europe.  In France that is 25mW (like WiFi).  It is
> not forbidden.  So I guess it can work.
> 
[FDC] Indeed lower frequencies do not alone reduce battery consumption. However, the propagation
at lower frequencies for a radio signal is better meaning that less transmit power at the device's antenna
 is needed to yield the same distance/range/coverage. 
The 802.11ah saves energy by allowing devices to sleep (doze) as mentioned in the draft. These techniques 
which allow devices to sleep are key power saving mechanisms.

> 
> It will offer a much lower bandwidth than WiFi, for much simpler applications
> (i.e. alarm on/off, window open/close rather than video stream at 11ad's 1GBps
> at 60GHz).  And because the amount of data transmitted is much lower that
> there will be energy savings.
[FDC] High bitrate systems e.g. 802.11ac/ad may be over-dimensioned for simpler applications. Here, allowing
devices to sleep save energy.

> 
> In that sense, I dont think there is anything to do to modify IPv6 to work on it.
> (and yes, IPv6 must work ok on 11ah, as it works on WiFi, and it is worth
> documenting in a document).
[FDC] In the draft it is clearly stated that LLC allows 802.11ah to use IPv6 by default. You have a point in the lower bitrate of 802.11ah.
Actually, this makes 802.11ah a perfect candidate for IPv6 header compression.
If packets are expected to be small, why we would like to send a large IPv6/UDP/whatever headers?. We want IPv6 
enabled devices, but with compressed headers.

> >>> 48-bit MAC device address.  Random IID can be generated for 6LN
> >>> using alternative methods such as [I-D.ietf-6man-default-iids]." Is
> >>> this sufficient?
> >>
> >> I think that "MAY" is good - it is good to refer to any I-D or RFC in
> >> this privacy space, to make the tracking based on MAC addresses more
> >> difficult to attackers.  The default-iids draft is good, and there is
> >> also RFC7217.
> >>
> > temperature sensors could be connected to internet through an 802.11ah
> > link.
> 
> smartphone can not get a shorter-than-64 prefix from a cellular operator, and
> as such can not send an RA containing a /64 on its 11ah interface - it will have to
> send a /65 in that RA.  Because of that an 11ah sensor connecting to the 11ah
> interface of the smartphone and forming an IID of length 64 will lead to IPv6
> address of length 129.
> That can not work.
[FDC] We need to study further this point. Do you have references that could enlighten us more with this respect? Maybe,
implementation documentation?

> 
> Also, an 11ah sensor would like to be able to talk using IPv6 to its 11b-only
> neighbor, both one the same hotspot emitted by a smartphone equipped of one
> single interface featuring all 11b/g/n/ac/ad/ah characteristics.  Right?
> 
[FDC] I think IPv6 will be this interface. 11ah talks IPv6 and other 11b device in the subnet talks IPv6, then they interoperate.
We are discussing the 6LoWPAN which is the adaptation layer before IPv6 in 11ah devices. 

> What I mean is to allow the smartphone to form an IID of length 48 out of the
> 48bit MAC address.  This will allow SLAAC to form 128bit IPv6 addresses when
> the RA contains a prefix of length 65.
> 
> If the RA contains a prefix of length 65 and the IID is of length 64 then the SLAAC
> will form addresses of length 129.
[FDC] We need to study further this point as mentioned above.

> It is strange to hear 'transport' because for me 'transport' is above IP not below
> it.  But be it.
> 
> >> still afforded even though an intermediary router must hold keys for
> >> eliminated/reinserted IPv6 base header?
> >>
> >
> IPv6 base header is eliminated and reconstructed by some intermediary then
> there is a risk of attack unless the keys are shared with some entity in the
> network - that sharing breaks e2e security: one doesnt want to share keys with
> any intermediary (MiTM) than the other end of the communication.
> 
[FDC] Thank you for your comments. They are very welcomed.

---

From: Felipe Del Carpio <[email-masked]>
Date: Thu, 18 Jun 2015 16:26:26 +0000

Dear Alexandru,

This security considerations needed to be study with more detail. I imagine that the comments are general to all
6LoWPAN specifications (802.15.4/BLE/etc.).

The IEEE 802.11ah specs defines only PHY(L1) and MAC(L2), they don't mention IPV4/IPv6 or 6LoWPAN in any way. This is the
reason to start this conversation on 6Lo WG.

Br, 
Felipe

> Sent: Thursday, June 18, 2015 7:00 PM
> Subject: Re: [6lo] New I-D draft-delcarpio-6lo-wlanah-00.txt - security
> 
> Dear Felipe,
> 
> Well, that draft seems to be trying to compress IPsec headers, similarly to
> LOWPAN_IPHC substituting new headers for RFC2460 IPv6 headers.
> 
> The risk includes faking LOWPAN_IPHC headers between two 11ah devices in
> the same subnet.
> 
> Waht do you think?
> 
> The transmission of IPv6 over 802.11ah links requires that IPsec works fine on
> them.  An IPv6 11ah-only device must be able to use IPsec to protect its IPv6
> communications with an IPv6 11b-only device in the same subnet.  And an IPv6
> 11ah-only device must be able to use IPsec to protect its IPv6 communications
> to an IPv6 11ah-only device across the Internet.
> 
> > The standard IEEE 802.11ah defines all those aspects related with Link
> > Layer security.
> 
> But neither of these (WPA, WPS, 802.1X) carry LOWPAN_IPHC headers as far as I
> know.  They carry IPv6 Base Headers, ethertype 0x86dd.
> 
> Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jun 2015 18:49:46 +0200

Dear Felipe,

Le 18/06/2015 18:16, Felipe Del Carpio a écrit :
[...]

>> But I dont think running at 863MHz will save any much energy,
>> instead of running at 2.4GHz.
>
> [FDC] Indeed lower frequencies do not alone reduce battery
> consumption. However, the propagation at lower frequencies for a
> radio signal is better meaning that less transmit power at the
> device's antenna is needed to yield the same
> distance/range/coverage.

I agree in general.  That is about places where these devices are
supposed to work.

> The 802.11ah saves energy by allowing devices to sleep (doze) as
> mentioned in the draft. These techniques which allow devices to sleep
> are key power saving mechanisms.

Ok, sleeping is fine to save energy.  But I dont think sleeping requires HC.

[...]

>> In that sense, I dont think there is anything to do to modify IPv6
>>  to work on it. (and yes, IPv6 must work ok on 11ah, as it works on
>>  WiFi, and it is worth documenting in a document).
>
> [FDC] In the draft it is clearly stated that LLC allows 802.11ah to
> use IPv6 by default.

I guess you talk about this text in the draft:
> IPv4 and IPv6 are compatible with 802.11ah via the LLC.

I fully agree.

But the draft further says:
> However, this technology presents a trade-off between energy savings
> and bit rate of the link.

I dont understand.  The LLC (Logical Link Control) headers dont contain
bitrate nor energy savings.  What do you mean more precisely?

> Consequently, 6LoWPAN techniques are beneficial to reduce the
> overhead of transmissions, save energy and get a better throughput.

Because I dont understand the above (LLC contain bitrate or energy
savings?) I dont understand why 6lowpan techniques are beneficial.

> You have a point in the lower bitrate of 802.11ah. Actually, this
> makes 802.11ah a perfect candidate for IPv6 header compression. If
> packets are expected to be small, why we would like to send a large
> IPv6/UDP/whatever headers?.

I agree in general it is questionable to send 40bytes of IPv6 Base
Header together with a byte of useful temperature value.

But the IPv6 Base Header contains fields which allow the 11ah node
to be fully connected to the entire Internet.

Would one want the 11ah node to be fully connected to any other 11ah
node in the Internet?  Or not?

If the app data needs to be sent locally only (i.e. from my remote
control unit to my door thermometer) then one wouldnt need IPv6 Base
Header at all, no IPv6 addresses either, no IPv6 altogether.

If on the other hand one wants IPv6 to work because the applications are
very easy to program on widely available cheap socket interfaces, with
much programming skillset available on market - then I must use the
entire IPv6 Base Header.  One cant come without the other.

> We want IPv6 enabled devices, but with compressed headers.

I am trying to parse but it's hard.

An IPv6 enabled device has IPv6 Base Headers mandatory.

Compressed headers (LOWPAN_IPHC) means there are no IPv6 Base Headers.
That means no IPv6.

I am confused by that.

But I agree we want a document that tells how to run IPv6 over 802.11ah.
  But I disagree to make that document too smart.

[...]

>>> [FDC] Indeed, the energy saving mechanisms are useful for
>>> battery operated devices like a Smartphone. Also connected
>>> sensors such as temperature sensors could be connected to
>>> internet through an 802.11ah link.
>>
>> If you agree this is for a smartphone, it would be good to note
>> that a smartphone can not get a shorter-than-64 prefix from a
>> cellular operator, and as such can not send an RA containing a /64
>>  on its 11ah interface - it will have to send a /65 in that RA.
>> Because of that an 11ah sensor connecting to the 11ah interface of
>>  the smartphone and forming an IID of length 64 will lead to IPv6
>> address of length 129. That can not work.
>
> [FDC] We need to study further this point. Do you have references
> that could enlighten us more with this respect? Maybe, implementation
> documentation?

YEs, the implementation is widely available.

Use linux/android on any smartphone.  Connect to any IPv6-enabled
cellular network.  Obtain an IPv6 address.  Type ifconfig -a.  See the
prefixlen is /64.  Listen to RAs with wireshark see the plen field in RA
is /64.  If you need I can send you a packet dump showing that.

All IPv6-enabled cellular networks act that way.  There isn't any which
would provide a shorter-than-64 prefix, or that would answer to DHCPv6
Prefix Delegation requests.

If all one gets from the access network is a /64, one can not make an
additional /64 out of it to put on the 11ah interface, so one is forced
to put a /65 in the 11ah interface.

This situation is approximately similar in many IPv6 WiFi hotspot
deployments: connect an IPv6 smartphone on an IPv6 hotspot in public
areas, at work, in many places, and note this /64.  But I did encounter
some exceptions of shorter-than-64 prefixes given to smartphones on
WiFi.  Never on cellular.

Is this explanation sufficient?  Can I clarify?

>> Also, an 11ah sensor would like to be able to talk using IPv6 to
>> its 11b-only neighbor, both one the same hotspot emitted by a
>> smartphone equipped of one single interface featuring all
>> 11b/g/n/ac/ad/ah characteristics.  Right?
>>
> [FDC] I think IPv6 will be this interface. 11ah talks IPv6 and other
>  11b device in the subnet talks IPv6, then they interoperate. We are
>  discussing the 6LoWPAN which is the adaptation layer before IPv6 in
>  11ah devices.

But an IPv6 11ah device will strip the IPv6 Base Header before sending
the packet to an 11b device in the same subnet (ad-hoc mode).  And no
11b device implements LOWPAN_HC so it can't reconstruct the IPv6 Base
Header.

Am I missing something?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jun 2015 19:04:38 +0200

Le 18/06/2015 18:26, Felipe Del Carpio a écrit :
> Dear Alexandru,
>
> This security considerations needed to be study with more detail. I
> imagine that the comments are general to all 6LoWPAN specifications
> (802.15.4/BLE/etc.).

In general one can say so.

But each of these drafts (BTLE, 15.4, 11ah, NFC, G-9x) are different.

> The IEEE 802.11ah specs defines only PHY(L1) and MAC(L2), they don't
> mention IPV4/IPv6 or 6LoWPAN in any way. This is the reason to start
> this conversation on 6Lo WG.

I think the IEEE specs should define much of what the LOWPAN_IPHC does.

And many IEEE 802.11 specs do talk IPv6.

Alex

>
> Br, Felipe
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Thursday, June 18, 2015
>> 7:00 PM To: Felipe Del Carpio; [email-masked] Cc: Roberto Morabito;
>> MARIA INES ROBLES Subject: Re: [6lo] New I-D
>> draft-delcarpio-6lo-wlanah-00.txt - security
>>
>> Dear Felipe,
>>
>> Le 18/06/2015 12:28, Felipe Del Carpio a écrit : [...]
>> +-----------+      +-----------+        ---------
>> +-----------+ |11ah device|------|IPv6 router|-------|Internet
>> |-----|11ah device| +-----------+      +-----------+
>> ---------      +-----------+
>>
>> Well, that draft seems to be trying to compress IPsec headers,
>> similarly to LOWPAN_IPHC substituting new headers for RFC2460 IPv6
>> headers.
>>
>> But the LOWPAN_IPHC header is insecure, whereas the IPv6 Base
>> Header is secured by IPsec.
>>
>> The risk includes faking LOWPAN_IPHC headers between two 11ah
>> devices in the same subnet.
>>
>> Waht do you think?
>>
>>> Indeed, the transmission of IPv6 over 802.11ah links meets all
>>> the requirements for security as for IEEE 802.15.4.
>>
>> No.
>>
>> The transmission of IPv6 over 802.11ah links requires that IPsec
>> works fine on them.  An IPv6 11ah-only device must be able to use
>> IPsec to protect its IPv6 communications with an IPv6 11b-only
>> device in the same subnet.  And an IPv6 11ah-only device must be
>> able to use IPsec to protect its IPv6 communications to an IPv6
>> 11ah-only device across the Internet.
>>
>>> As well as for other existing WiFi solutions, 802.11ah Link
>>> Layer supports security mechanism such as WPA, WPS, 802.1X.
>>
>> But neither of these (WPA, WPS, 802.1X) carry LOWPAN_IPHC headers
>> as far as I know.  They carry IPv6 Base Headers, ethertype 0x86dd.
>>
>> Alex
>
>