Subject: Re: [ipwave] Review of draft-ietf-ipwave-ipv6-over-80211ocb-25

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Sep 2018 14:25:37 +0200

Le 18/07/2018 à 17:03, Erik Nordmark a écrit :
> 
> I volunteered (or was volunteered) to review this document during the 
> ipwave meeting this week.
> Here are my comments and suggested modifications.
> 
> 
> Level 0. My assumption is that the OCB interface (in vehicles and 
> infrastructure nodes) are attached to a router, and not a host. Is that 
> correct?
> That assumption has a significant implication on the subnet/ND material.
> (And appendix H talks about hosts!)

For completeness, I would like to add that there are some hw 
manufacturers proposing cheap dedicated 802.11-OCB boxes without IP 
forwarding functionality. These could be the ones to consider as Hosts. 
Often called a "DSRC box", it is an aftermarket add-on to a car.  It 
beacons some messages (not IP) and receives others' beacons on the same 
interface.  It does not run IP as of today.  If it did IP it were an IP 
Host.

I speculate a certain market future for such small cheap devices (under 
100eur), as more and more highways are equipped with RSUs sending live 
data about traffic state.

Also, some deployed Road-Side Units do send Router Advertisements on 
802.11-OCB, even though they do not forward packets between their 
802.11-OCB interface and their Ethernet interface.  These would be 
Non-Forwarding Routers.  One could consider them to be Hosts that 
wrongly send RAs instead of NAs.

That said, I would not oppose the draft to not talk about these Hosts.

The question would be what would be the implications to the subnet/ND 
material if we only discussed Routers.

Alex

> 
> 
> Section 4.5: "see the privacy considerations described in Appendix F."
> I think the key privacy considerations are (or should be if something is 
> missing) in the security considerations section and not in an appendix.
> Appendix F provides useful background and design considerations, but I 
> think this reference to appendix F is confusing.
> 
> Section 4.3:
> I think the section should explicitly say that at most the link-local 
> address can use the EUI-64 based interface identifier, by saying that 
> any other IPv6 address should use either RFC8064 or RFC7217. I think 
> that is the intent, but the wording doesn't make it clear.
> 
> Section 4.6 first paragraph:
> I don't understand why there needs to be a subnet prefix assigned to the 
> ephemeral connectivity between the vehicles in range. AFAIU that is 
> router to router communication which can use link-local IPv6 addresses.
> The routing protocols I know can operate using link-local addresses.
> 
> Section 4.6 third paragraph:
> 802.11 does not provide reliability for the ND multicast messages.
> Thus I don't think OCB is any different than 802.11 in this respect.
> I think this paragraph can be removed. If not, it should say the 
> opposite of that it says right now.
> 
> Section 4.6 forth paragraph:
> I don't know why one would have a mobile host directly attached to the 
> OCB link. My understanding is that only routers are attached to the OCB 
> link. Is that correct?
> 
> In summary I think section 4.6 should say that the OCB link might not 
> have any IP address prefix apart from the link-local prefix.
> 
> If it does have some other IP prefix, then one would need to determine 
> who would advertise that/those prefixes (will the infrastructure nodes 
> send RAs with prefixes? Each vehicle??)
> 
> After the reference to RFC5889 it might make sense to explicitly restate 
> this from that RFC:
>     o  no on-link subnet prefix should be configured on such an
>        interface.
> 
> RFC5889 seems to suggest that it would be useful and in some cases 
> required to configure a non-link-local address for the OCB interface. 
> But such an address would probably need to be checked for uniqness in 
> the routing domain, and it isn't clear to me whether that would fit the 
> timing requirements for v2x.
> 
> Section 5 IPSec and SeND discussion. I'll defer to security experts on 
> this. I suspect it requires a separate draft to specify how IPsec and/or 
> SeND can be part of a security solution.
> 
> Section 5 last paragraph. I think this section should say at the instant 
> the MAC address is changed on the OCB interface, the node needs to also 
> change all of the IIDs on the OCB interface (link-local and any globals).
> 
> Section 5 last paragraph. I don't understand what this text is trying to 
> say and I suggest it be dropped:
>     On another hand, it may
>     have an impact in the way typical IPv6 address auto-configuration is
>     performed for vehicles (SLAAC would rely on MAC addresses and would
>     hence dynamically change the affected IP address), in the way the
>     IPv6 Privacy addresses were used, and other effects.
> 
> The actual policy for when the MAC address is changed on the OCB 
> interface is presumably to-be-determined. Might make sense to note that 
> in the text. I note there is some mention of this in appendix C thus it 
> might make sense to add a reference to that appendix.
> 
> Appendix C last paragraph:
> The "may have an influence" followed by the reference to 4.6 seems to 
> imply that something special is going on in section 4.6 which isn't 
> there. That's confusing. I suggest dropping that paragraph.
> 
> Appendix F.4 uses the term pseudonyme without ever defining it. Hence it 
> isn't clear what the stated requirement is.
> 
> Appendix H refers to a geolocation database and a GeoIP, yet the 
> changelog claims that those concepts have been removed from the 
> document. (I don't know how useful appendix H is to an implementor. It 
> isn't about how to implement things but what wireshark will show so 
> doesn't match the name of the section.)
> 
> Appendix I seems misplaced.
> If the reader needs to know these terms, then they should be in the 
> terminology section and not in an appendix. If the reader doesn't need 
> to know then, then they don't need to be in the document.
> 
> Note that the document has a lot more of appendix text than body text. 
> It is a 15 page document with 25 pages of appendices.
> I don't know how useful those appendices will be to a new reader; they 
> might have been useful as part of producing the document. But might want 
> to consider which part of the appendices are still needed.
> 
>     Erik
> 
> 
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Sep 2018 14:42:53 +0200

Hi Erik,

[...]
> doesn't match the name of the section.)

'GeoIP' is the name given by wireshark to a mechanism that associates a 
cityname to an IP address.  This 'GeoIP' is altogether different than 
the GeoNetworking IP of ETSI, and that of the failed IETF GeoNet BoF.

That said, I believe the appendix H _is_ useful to implementor because 
it shows detailed packet dumps.  Probably the 'GeoIP' text is not 
useful, and potentially misleading because of this risk of 
misunderstanding with GeoNetworking.  I will remove that GeoIP text, but 
keep the appendix.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Sep 2018 11:49:17 +0200

> think this reference to appendix F is confusing.

Moved some parts from section 4.5 and from other place into a new 
'Privacy Considerations' sub-section of the Security Considerations section.

> that is the intent, but the wording doesn't make it clear.

Reformulated the SLAAC and LL sections.

> The routing protocols I know can operate using link-local addresses.

Clarified the paragraph.

> opposite of that it says right now.

I remove it, but I let the last phrase "ND is used over OCB" if that is ok.

> OCB link. My understanding is that only routers are attached to the OCB 

Typically it should be a router, indeed.

Do you mean we should not mention the operation of Mobile IPv6?  At the 
moment I keep it.

> have any IP address prefix apart from the link-local prefix.

Added a sentence in that way.

> send RAs with prefixes? Each vehicle??)

Some infrastructure IP-RSU nodes do send RAs with GUA and ULA prefixes 
towards cars.  I dont think we want to rule them out.

Vehicles do not send RAs with GUA nor ULA prefixes.  Some vehicles do 
send RAs but with no prefix inside.

>     o  no on-link subnet prefix should be configured on such an

I add it, because the 'should' is not in capitals.

> timing requirements for v2x.

That is a good remark.  The timing requirements are something like this 
live environment: a car at 110km/h stays within the coverage of an 
IP-RSU for approximately 5 seconds.  Each 2ms a message can be sent or 
received.

During that time, it is possible to exchange some application data 
packets (http GET state of traffic), and, probably, or probably not, 
possible to verify uniqueness of address in the routing domain.

> SeND can be part of a security solution.

Ok then: for the moment I leave it that way.

> change all of the IIDs on the OCB interface (link-local and any globals).

Added a phrase in that sense.

>     IPv6 Privacy addresses were used, and other effects.

Dropped.

> might make sense to add a reference to that appendix.

Noted that in text, and reference added.

> there. That's confusing. I suggest dropping that paragraph.

Dropped.

> isn't clear what the stated requirement is.

Dropped the phrase saying 'pseudonyme'.  I think it is not necessary to 
change all addresses on all interfaces when the change in pseudonym occurs.	

> doesn't match the name of the section.)

Changed the title to: example of packet formats.

> to know then, then they don't need to be in the document.

The appendix has basic terms that are needed by the terms in the 
Terminology (e.g. appendix defines IP-OBU using the term OBU).  The main 
text in the draft does not use the terms defined in the appendix.

We find that too many terms in the Terminology section may clutter the 
view unnecessarily.

> to consider which part of the appendices are still needed.

I tend to agree.

Probably I could remove appendices C, D, E, F and G for a total of 10 
pages, if there is no strong disagreement.

The titles of these appendices are:
802.11p
Aspects introduced by the OCB mode to 802.11
Changes Needed on a software driver 802.11a to become a 
802.11-OCB driver
EtherType Protocol Discrimination (EPD)
Design Considerations
IEEE 802.11 Messages Transmitted in OCB mode

Alex