Subject: Re: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01

From: Charlie Perkins <[email-masked]>
Date: Wed, 20 Jul 2016 04:08:36 -0700

Hello Chris,

Thanks for your review of this document.  Your email somehow eluded my 
attention until today, please excuse the delay.

Follow-up below...

On 5/26/2016 9:27 AM, Dearlove, Christopher (UK) wrote:
>
> I haven’t yet found time to read this (I’m still hoping to before 
> indicated date).
>
> But one thing immediately jumps out.
>
> The document references the four Experimental protocols produced by 
> the MANET WG. It references a draft produced for OSPF. From 
> recollection, there were three separate drafts produced for OSPF, all 
> of which became Experimental RFCs. But two are not referred to.
>

I found the following:
> OSPF (<xref target="RFC5449"/>, <xref target="RFC5820"/> and <xref 
> target="RFC7137"/>)

If there are others please let me know.

> But there is also a Proposed Standard MANET routing protocol, OLSRv2, 
> RFC 7181.
>

Fixed.

>
> There are of course many other protocols; the only other one that I’m 
> aware of and might need mentioning (here I need to read the draft) is 
> NHDP (RFC 6130). This can be viewed as the neighbourhood discovery 
> part of OLSRv2, but is specified as a separate protocol. Some of this 
> paper is about neighbours, and possibly it may be appropriate to 
> reference RFC 6130, but also possibly it might not. (I’m an author of 
> that RFC too.)
>
> While posting, but nits, two other things jumped out at me. One is the 
> white space on page 6.
>

Fixed!

> The other (since I was looking at references) is the rather odd 
> reference DoD01 with two authors, then a title, then an editor. Of 
> course the RFC Editor would in due course change this to whatever is 
> approved style, but might as well get it closer.
>
> And now, looking at my records, I see I have already made (and since 
> forgotten) my main comment (though I didn’t then discuss the OSPF 
> situation) in January, and nothing was done, though there was an 
> indication it should be then. I don’t think this should have proceeded 
> to WGLC with that unaddressed.
>

I'll try to go find that comment, but in case I don't find it please 
note that we have made a good bit more discussion about security in 
Section 5.

> That trip into records indicated there was a comment then (not from 
> me) about the security considerations section. It’s worth noting that 
> there’s a security framework for OLSRv2, and other protocols to use 
> the manet part/protocol (as specified in RFC 5498) in RFC 7182.
>

This document isn't really about securing multi-hop communications 
routing protocols, but instead it is about certain characteristics of 
the underlying medium over which such protocols run.  Do you think there 
is something particular about the security considerations in RFC 7182 
that has to do with asymmetry, non-transitivity, or time variance?  If 
so I would be happy to indicate that in the document and cite the 
relevant material.  Or, if there is a relevant discussion about MitM 
attacks, that could merit a specific citation.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 20 Jul 2016 04:14:18 -0700

Hello again Chris,

I forgot to mention the reference DoD01.  This is a book chapter by 
James Freebersyser and Barry Leiner in a book that I edited. Do you mean 
to suggest that I should delete the part of the citation about the 
book's editorship?  I don't really know how best to format the citation.

Regards,
Charlie P.

On 5/26/2016 9:27 AM, Dearlove, Christopher (UK) wrote:
> RFC 7181. Its omission is clearly quite wrong. Which indicates a 
> rewriting of Section 2 at least. ( I’m an author of that RFC. But I 
> think it’s pretty objective that it should be there. And I have no 
> connection to the OSPF drafts, and I think it’s pretty objective all 
> or none - and I see no reason why not all - should be there.)
>
> white space on page 6. The other (since I was looking at references) 
> is the rather odd reference DoD01 with two authors, then a title, then 
> an editor. Of course the RFC Editor would in due course change this to 
> whatever is approved style, but might as well get it closer.
>
> *-- *
> *Christopher Dearlove
> Senior Principal Engineer
> BAE Systems Applied Intelligence Laboratories
> **__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  | *E: [email-masked] 
> <mailto:[email-masked]>
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great 
> Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai <http://www.baesystems.com/ai>
>
> BAE Systems Applied Intelligence Limited
> Registered in England & Wales No: 01337451
>
> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>
> *From:*Int-area [mailto:[email-masked]] *On Behalf Of *Juan 
> Carlos Zuniga
> *Sent:* 16 May 2016 17:34
> *To:* [email-masked]
> *Subject:* [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01
>
> **** WARNING ****
>
> /This message originates from outside our organisation, either from an 
> external partner or the internet.//
> /Consider carefully whether you should click on any links, open any 
> attachments or reply./
> /For information regarding //*/Red Flags/*/that you can look out for 
> in emails you receive, click here 
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.//
> /If you feel the email is suspicious, please follow this process 
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.//
>
> Dear Int-Area WG,
>
> The draft-ietf-intarea-adhoc-wireless-com has been discussed in 
> several occasions and we believe that the latest version addresses all 
> the comments that have been made.
>
> This email starts an Int-Area WG Last Call on:
>
> https://tools.ietf.org/html/draft-ietf-intarea-adhoc-wireless-com-01
>
> Please respond to this email to support the document and/or send 
> comments by 2016-05-30.
>
> In addition, to satisfy RFC 6702 "Promoting Compliance with 
> Intellectual Property Rights (IPR)":
>
> Are you personally aware of any IPR that applies to 
> draft-ietf-intarea-adhoc-wireless-com?
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules?
>
> (See RFCs 3979, 4879, 3669, and 5378 for more details.)
>
> Best,
>
> Juan Carlos Zuniga & Wassim Haddad
>
> (Int-Area WG co-chairs)
>
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>
>
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 20 Jul 2016 11:20:55 +0000

The reference is one of those "I happened to notice" things. As I noted, this could be left to RFC Editor. Or a query made ahead of time (I think they are quite friendly). But it's not important (and had I note had other points, I'd not have mentioned it, it was a "since I'm posting" thing).

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: Charlie Perkins [mailto:[email-masked]]
Sent: 20 July 2016 12:14
To: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.

Hello again Chris,

I forgot to mention the reference DoD01.  This is a book chapter by James Freebersyser and Barry Leiner in a book that I edited.  Do you mean to suggest that I should delete the part of the citation about the book's editorship?  I don't really know how best to format the citation.

Regards,
Charlie P.

On 5/26/2016 9:27 AM, Dearlove, Christopher (UK) wrote:
I haven't yet found time to read this (I'm still hoping to before indicated date).

The document references the four Experimental protocols produced by the MANET WG. It references a draft produced for OSPF. From recollection, there were three separate drafts produced for OSPF, all of which became Experimental RFCs. But two are not referred to.

But there is also a Proposed Standard MANET routing protocol, OLSRv2, RFC 7181. Its omission is clearly quite wrong. Which indicates a rewriting of Section 2 at least. ( I'm an author of that RFC. But I think it's pretty objective that it should be there. And I have no connection to the OSPF drafts, and I think it's pretty objective all or none - and I see no reason why not all - should be there.)

There are of course many other protocols; the only other one that I'm aware of and might need mentioning (here I need to read the draft) is NHDP (RFC 6130). This can be viewed as the neighbourhood discovery part of OLSRv2, but is specified as a separate protocol. Some of this paper is about neighbours, and possibly it may be appropriate to reference RFC 6130, but also possibly it might not. (I'm an author of that RFC too.)

While posting, but nits, two other things jumped out at me. One is the white space on page 6. The other (since I was looking at references) is the rather odd reference DoD01 with two authors, then a title, then an editor. Of course the RFC Editor would in due course change this to whatever is approved style, but might as well get it closer.

And now, looking at my records, I see I have already made (and since forgotten) my main comment (though I didn't then discuss the OSPF situation) in January, and nothing was done, though there was an indication it should be then. I don't think this should have proceeded to WGLC with that unaddressed.

That trip into records indicated there was a comment then (not from me) about the security considerations section. It's worth noting that there's a security framework for OLSRv2, and other protocols to use the manet part/protocol (as specified in RFC 5498) in RFC 7182.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: Int-area [mailto:[email-masked]] On Behalf Of Juan Carlos Zuniga
Sent: 16 May 2016 17:34
To: [email-masked]<mailto:[email-masked]>
Subject: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
Dear Int-Area WG,

The draft-ietf-intarea-adhoc-wireless-com has been discussed in several occasions and we believe that the latest version addresses all the comments that have been made.

Please respond to this email to support the document and/or send comments by 2016-05-30.

In addition, to satisfy RFC 6702 "Promoting Compliance with Intellectual Property Rights (IPR)":
Are you personally aware of any IPR that applies to draft-ietf-intarea-adhoc-wireless-com?
If so, has this IPR been disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)

Best,

Int-area mailing list

[email-masked]<mailto:[email-masked]>

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 20 Jul 2016 04:25:51 -0700

Hello Alex,

Please excuse my delay in answering -- your email got buried in a mass 
flood of other emails.  Follow-up below...

On 5/18/2016 4:37 AM, Alexandre Petrescu wrote:
> Hello,
>
> I would like to give a few comments on this draft.

Thanks much for your review!

>
> It says:
>> For the purposes of this document, a multi-hop ad hoc wireless
>> network will be considered to be a collection of devices that each
>> have a radio transceiver (i.e., wireless network interface), and that
>> are moreover configured to self-organize and provide store-and-
>> forward functionality as needed to enable communications.
>
> 1.  when it says 'multi-hop', it actually means multiple-layer2-hops,
>     not multiple-IP-hops in particular, right?

Actually, we did have in mind multiple IP hops, but the IP hops could 
naturally be considered to be single physical-layer links. For 
situations in which the IP hop is composed of multiple layer-2 hops, 
then the nature of the layer-2 (?bridge?mesh-under?) protocol makes all 
the difference about whether or not the effects described in our draft 
are relevant.  For instance, layer 2 could counteract effects of time 
variations.

>
> 2.  each node has a wireless network interface: yes, not two.

We do not place this constraint.  I will clarify that.

>
>
>> These deployments use routers running IP protocols e.g., OLSR
>> (Optimized Link State Routing [RFC3626]) on top of IEEE 802.11 in ad
>> hoc mode with the same ESSID (Extended Service Set Identification) at
>> the link layer.
>
> 3.  Please note there is no RFC that specifies how to run IP on top of
>     802.11.  One can say OLSR runs on top of 802.11, but at the same
>     time there is no RFC that tells how _IP_ runs on it, as "IPv6 over
>     foo".  I think this is worth mentioning in the draft.

And yet people run IP over 802.11 without significant difficulty, so 
perhaps the consensus has been that such a specification is not urgently 
needed.

>
>> Wireless communications are subject to limitations to the distance
>> across which they may be established.
>
> 4.  This distance limitation in itself is not enough to distinguish
>     wireless communications from wired communications.   In
>     wired communications limits on the distance apply as well.  In that
>     sense, it should say "Wireless communications - like all other
>     communication media - are subject to limitations [...]"

Yes, but the limitations are much more pronounced with wireless media.

What would you think of the following:

> Wireless communications are particularly subject to limitations to
> the distance across which they may be established.

>
>
>> The range-limitation factor creates specific problems on multi-hop ad
>> hoc wireless networks.  In this context, the radio ranges of several
>> devices often partially overlap.
>
> 5.  The overlapping is indeed particular to wireless communications
>     (not seen in wires).  However, overlapping is due to the lack of
> isolation between the guides, not because of a distance range: whereas
> each wire is always isolated by a plastic shield leaving only two ends
> open (two wires wouldn't overlap), in wireless 802.11 the 'channeled'
> transmission can have many open ends at different distance from one
> another (some would overlap).

How about:

>     ....   Due to the lack of isolation between the transmitters,
>     the radio ranges of several devices often partially overlap, ...

>
>> Moreover, the range may vary from one device to another, depending
>> on location and environmental factors.
>
> 6. This is true, but 'from one device to another' sounds ambiguous:
> distance from A to B?  Or 'range of reach by emission from A, is
> different than the reach of reach by emission from B, depending on
> environmental factors like solid obstacles, rain, and more'.

How about the following:

>                                  ....... Moreover, the range of each
> device may
>     depend on location and environmental factors.

Thanks for your comments.  I will submit a revision today that 
incorporates the above text in an attempt to resolve the issues you have 
raised.  Please take a look.

Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 20 Jul 2016 11:28:45 +0000

Security considerations generally fall in two parts (a) that which is essential to the matter in hand, and (b) that which is needed to show people - especially SEC ADs - that you've really thought about the problem. I'd agree that 7182 does not fall under (a). Whether it falls under (b) as a "will mention as part of a rounded picture" is a borderline case.

As for OSPF, my recollection was three and you've found three. I'd guess that's right then. That was one of my only two "definitely should do" issues, the other being to include 7181. I haven't yet seen what revisions you've made, but it's PS, I think everything else is EXP, so that should be clear.

(All three are experimental, it would actually be interesting to know which have gone anywhere. But that's a RTG question, not an INT question.)

Sent: 20 July 2016 12:09

*** WARNING ***

Hello Chris,

Thanks for your review of this document.  Your email somehow eluded my attention until today, please excuse the delay.

Follow-up below...

I found the following:

OSPF (<xref target="RFC5449"/>, <xref target="RFC5820"/> and <xref target="RFC7137"/>)

But there is also a Proposed Standard MANET routing protocol, OLSRv2, RFC 7181.

Fixed.

While posting, but nits, two other things jumped out at me. One is the white space on page 6.

Fixed!

The other (since I was looking at references) is the rather odd reference DoD01 with two authors, then a title, then an editor. Of course the RFC Editor would in due course change this to whatever is approved style, but might as well get it closer.

I'll try to go find that comment, but in case I don't find it please note that we have made a good bit more discussion about security in Section 5.

This document isn't really about securing multi-hop communications routing protocols, but instead it is about certain characteristics of the underlying medium over which such protocols run.  Do you think there is something particular about the security considerations in RFC 7182 that has to do with asymmetry, non-transitivity, or time variance?  If so I would be happy to indicate that in the document and cite the relevant material.  Or, if there is a relevant discussion about MitM attacks, that could merit a specific citation.

Regards,
Charlie P.