Subject: Re: [its] I-D Action: draft-li-ipv4-over-80211ocb-00.txt

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Dec 2016 10:20:58 +0100

I support this draft.

Even though IPv4 is not in the [ipwave] charter there is requirement for
IPv4 prototypes in vehicular networks on 802.11-OCB, at least at this time.

Informally speaking, I would like to ask whether at your organization
there is now, or planned, prototype implementation of running IPv4 over
802.11-OCB.  I am asking because in the past we have played with some
vehicular 'Mobile Router' platform from some provider: it did feature
IPv4 but mostly on LTE, not on 802.11-OCB at 5.9GHz.  Maybe this changed...

Alex

Le 01/12/2016 à 06:35, Gonzalo Salgueiro (gsalguei) a écrit :
> Hi IPWAVErs -
>
> We have just published a draft documenting how IPv4 is encoded over
> 802.11OCB.  You can find it here:
>
> https://tools.ietf.org/html/draft-li-ipv4-over-80211ocb-00
>
> We are fully aware that the WG is focused on IPv6 and that in Seoul
> there was consensus to remove IPv4 from
> draft-petrescu-ipv6-over-80211p. I believe that at the last meeting
> the decision was to use an individual submission for IPv4 and that
> WG/chairs would determine how best to coordinate with this.
>
> I speak for the other authors and collaborators of this draft when I
> say that we’re all strongly in favor of an IPv6 focus for the WG.
> It seems we may have a subtle disagreement on the need to simply
> document how IPv4 is to be encoded, especially in light of how
> consistent the alignment is with IPv6.  Obviously, our preference
> would be for the work (IPv4 over 802.11OCB) to be done officially by
> the WG since it seems an almost trivial exercise and with minimal
> overhead.  That said, we’re not here to trump WG consensus, so at
> this point we are making the WG aware of the existence of this draft
> and looking for any reviews and comments to improve the document.
> Additionally, we’d greatly appreciate any coordination assistance
> and guidance on how best (and most efficiently) to get this
> individual submission progressed.
>
> Thanks,
>
> Gonzalo
>
>
>> On Nov 30, 2016, at 4:43 PM, [email-masked]
>> <mailto:[email-masked]> wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>  directories.
>>
>>
>> Title           : Transmission of IPv4 over IEEE 802.11 in OCB mode
>> Authors         : Tony Li Gonzalo Salgueiro Dino Farinacci Filename
>> : draft-li-ipv4-over-80211ocb-00.txt Pages : 12 Date            :
>> 2016-11-30
>>
>> Abstract: This document describes the transmission of IPv4 packets
>> over IEEE 802.11-2012 networks when run Outside the Context of a
>> BSS (802.11-OCB, earlier known as 802.11p).
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-li-ipv4-over-80211ocb/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-li-ipv4-over-80211ocb-00
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________ I-D-Announce
>> mailing list [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft
>> directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: "Dr. Karan Verma" <[email-masked]>
Date: Fri, 2 Dec 2016 15:34:43 +0530

I read your draft and wrote some point may be help full your revise draft

Description about: Transmission of IPv4 and ARP packets over IEEE
802.11-2012 or IEEE 802.11-OCB for vehicles, when run Outside the Context
of a BSS (Basic service set).

It only describes encapsulation of IPv4 packets.

·         IEEE 802.11-OCB earlier known as 802.11p.

·         Encapsulation process of IPv4: According to IEEE802.11-OCB (IPv4
packets are encapsulated in a LLC SNAP layer and then the 802.11 MAC layer
before transmission.)

* *

                 SNAP-Subnetwork access protocol

                 LLC-Logical Link Control

IPv4 packets can be transmitted as "IEEE 802.11 Data" or alternatively as
"IEEE 802.11 QoS Data". Thus, formatted frames may appear in either of
these formats:

Value of Type/subtype field differs according to formats:

 802.11 Data header: 0x20 (Data, Data)

 802.11 QoS header: 0x28 (Data, QoS Data)

 *Adaptation Layer:* These formats are slightly different than standard
Ethernet framing for IPv4, so implementations must use an adaptation layer
in between MAC and N/w layer to *merge up the difference* so that the
network layer perceives traditional Ethernet encapsulation.

·         Translated encapsulation is not sent over the 802.11-OCB network,
but is instead presented by the device driver to the operating system. This
allows 802.11-OCB interfaces to easily take advantage of all of the
operating system facilities that exist for Ethernet already.

·         MTU (Maximum transmission unit) size for IPv4 packets on
802.11-OCB is 1500 octets.

·         If a packet is fragmented by the IPv4 network layer before
transmission on 802.11-OCB, the field "Sequence number" in the 802.11 Data
header should increment for each fragment and the "Fragment number" field
should remain 0. This is recommended because the link layer cannot do IP
fragment reassembly.

IPv4 unicast addressing strategies are:

·         Static addressing

·          DHCP with network assigned addresses [RFC2131]

·          DHCP with private addressing and NAT [RFC1918] [RFC3022]

·         Link-local addressing [RFC3927]

Advantages

·          802.11-OCB already attempts to assist with privacy by having a
station change its MAC address.

Drawbacks:

·         Link layer does not provide any authentication mechanism.

·         The L2 headers of IEEE 802.11-OCB and L3 headers of IPv4 are not
encrypted, and expose the MAC address and IP address of both the source and
destination. Adversaries could monitor the L2 or L3 headers, track the
addresses, and through that track the position of a vehicle over time.

·         MAC address randomization will not prevent tracking if the
address stays constant for long intervals. If renumbering events are too
infrequent, they will not protect privacy, but if they are too frequent
they will disrupt service.

·         If any of the addresses stops working, traffic continues to flow
on the working addresses. However, in this situation, advertising multiple
addresses would defeat the privacy goals.

Remarks:

·         IPsec can be used to protect unicast communications. If no
protection is used by the IP layer, upper layers should be
cryptographically protected.

·         802.11-OCB provides no link level security, some hosts may choose
to implement cryptographic techniques to provide data privacy and
authentication.

·         Key exchange needs to be performed prior to the exchange of other
key information. Simply transmitting constant certificates can violate the
privacy requirements. To preserve privacy, a host must change its
certificate any time it has a renumbering event.

·         Hosts would be able to maintain transport connections across
renumbering events by making use of multipath TCP.

Thank You

On Thu, Dec 1, 2016 at 2:50 PM, Alexandre Petrescu <
[email-masked]> wrote:

> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

-- 
Best Regards

*Dr. Karan Verma *
Assistant Professor
Computer Science and Engineering Dept.
Central University Rajasthan, India
Website: www.drkaranverma.com
Phone: +917568169258

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Dec 2016 11:16:26 +0100

Hi Dr. Verma,

I would like to say that I am not co-author of this 
draft-li-ipv4-over-80211ocb-00.txt, but I support it.

Additionally, I do not understand which part of the text are your 
comments.  Could you please specify which are your comments and which is 
the text from the draft?  In this way the authors may take it into 
consideration.

On the email lists at IETF there is common practice of talking like this:

person1 said:
 >>> bit is leftmost
 >> person2 said:
 > bit is rightmost

Remark the use of '>' for indenting and the atribution of persons to 
text.  Common email programs realize that indentation automatically when 
one presses the 'Reply'.

Alex

Le 02/12/2016 à 11:04, Dr. Karan Verma a écrit :
> 802.11-2012 or IEEE 802.11-OCB for vehicles, when run Outside the
> Context of a BSS (Basic service set).
>
> ·         Encapsulation process of IPv4: According to IEEE802.11-OCB
> (IPv4 packets are encapsulated in a LLC SNAP layer and then the 802.11
> MAC layer before transmission.)
>
> 	
>
> /Inline image 1 // //
>
>                                             /
>
>
>
> IPv4 packets can be transmitted as "IEEE 802.11 Data" or alternatively
> as "IEEE 802.11 QoS Data". Thus, formatted frames may appear in either
> of these formats:
>
> Inline image 2
>
>  *Adaptation Layer:*These formats are slightly different than standard
> Ethernet framing for IPv4, so implementations must use an adaptation
> layer in between MAC and N/w layer to *merge up the difference* so that
> the network layer perceives traditional Ethernet encapsulation.
>
> * *
>
> Inline image 3* *
>
> * *
>
> ·         Translated encapsulation is not sent over the 802.11-OCB
> network, but is instead presented by the device driver to the operating
> system. This allows 802.11-OCB interfaces to easily take advantage of
> all of the operating system facilities that exist for Ethernet already.
>
> transmission on 802.11-OCB, the field "Sequence number" in the 802.11
> Data header should increment for each fragment and the "Fragment number"
> field should remain 0. This is recommended because the link layer cannot
> do IP fragment reassembly.
>
> ·          802.11-OCB already attempts to assist with privacy by having
> a station change its MAC address.
>
> Drawbacks:
>
> ·         The L2 headers of IEEE 802.11-OCB and L3 headers of IPv4 are
> not encrypted, and expose the MAC address and IP address of both the
> source and destination. Adversaries could monitor the L2 or L3 headers,
> track the addresses, and through that track the position of a vehicle
> over time.
>
> ·         If any of the addresses stops working, traffic continues to
> flow on the working addresses. However, in this situation, advertising
> multiple addresses would defeat the privacy goals.
>
> Remarks:
>
> ·         802.11-OCB provides no link level security, some hosts may
> choose to implement cryptographic techniques to provide data privacy and
> authentication.
>
> ·         Key exchange needs to be performed prior to the exchange of
> other key information. Simply transmitting constant certificates can
> violate the privacy requirements. To preserve privacy, a host must
> change its certificate any time it has a renumbering event.
>
> On Thu, Dec 1, 2016 at 2:50 PM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I support this draft.
>
>         <https://tools.ietf.org/html/draft-li-ipv4-over-80211ocb-00>
>
>             <mailto:[email-masked]>
>             <mailto:[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>
>             https://datatracker.ietf.org/doc/draft-li-ipv4-over-80211ocb/ <https://datatracker.ietf.org/doc/draft-li-ipv4-over-80211ocb/>
>
>             <https://tools.ietf.org/html/draft-li-ipv4-over-80211ocb-00>
>
>
>             tools.ietf.org <http://tools.ietf.org>.
>
>             <ftp://ftp.ietf.org/internet-drafts/>
>
>             <mailto:[email-masked]>
>             https://www.ietf.org/mailman/listinfo/i-d-announce
>             <https://www.ietf.org/mailman/listinfo/i-d-announce>
>             Internet-Draft
>             directories: http://www.ietf.org/shadow.html
>             <http://www.ietf.org/shadow.html> or
>             <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
>
>
>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/its>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/its>
>
>
>
>
> --
> Best Regards
>
> */Dr. Karan Verma /*
> Assistant Professor
> Website: www.drkaranverma.com <http://www.drkaranverma.com/>
> Phone: +917568169258