Subject: [manet] draft-ietf-manet-olsrv2-management-snapshot-02

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 21 Aug 2014 17:24:11 +0000

I failed to get any review comments in on draft-ietf-manet-olsrv2-management-snapshot-02 in before WGLC end. As such if I want any comments considered, I will have to put them in at IETF review.

Whether or not I do that, here are some comments. To be clear, I'm the document shepherd for this document, but that hat is off in making these comments.

(There are a couple of editorial errors that with that hat back on do need fixing to avoid every reviewer making them. The authors were already aware of these, though I wasn't aware they were aware, but there will need to be a -03 to fix those for beyond the WG. Anyway, hat back off.)

"C" is referred to as a parameter. That's appropriate at the management level, but slightly confusing when put up against 6130/7181 which define it as a constant, a separate category from parameters. I think I might have suggested a comment in one place on that.

The introduction could also list 7187 and 7188, but I'm not sure if there's any gain there.

1.1   says this applies to some networks, while the abstract says typical. Not quite the same thing.

3.1 could (as Henning might well point out) say that while the messages and protocol instantiations are separate, the message could share a packet.  Though there are some implications of saying so in terms of the 5444 multiplexing not quite stated  assumptions.

3.1 second paragraph I might have mentioned MAC as well as radio channel. But definitely not necessary.

3.2 first paragraph "an IP address" might have been clearer as "a single IP address".

3.2, it is actually possible to have dynamic MANET interface addresses. Especially if you change from address A to address B going via A and B for continuity.

3.3 Was "USB key" meant? Overloads the word key.

3.3 paragraph 3. It's probably obvious to everyone interested in MANETs that there's a chicken and egg problem in using the routing fabric you are constructing to distribute the keys to establish that fabric. But not necessarily to everyone else. (I'm not suggesting this is insoluble of course.)

4.1 Minimum intervals are not discussed anywhere, but can have a significant effect (see also section 5 comment).

4.2 I can confirm some things speculated about here are not just speculation - but I have no public domain information to back that up. (I suspect the authors' position is similar.)

5. You can survive a long HELLO_INTERVAL if you operate all of the permitted responsive mechanisms (to send a HELLO when things change) and minimum intervals are small. Except that one HELLO may get lost, and now we would have to consider how to behave. (One possibility is to reduce HELLO_INTERVAL to minimum for a few HELLO messages, then put it back up.) Details are beyond this document, but I think that here and/or 4.1 some comment on minimum intervals would be useful. (Better still would be a longer discussion, but that's for another document another day.)

7 (which has an odd mixed-case title) is "reflective" meant rather than "reflexive"?

9 An example attack  following directly from earlier in the document is to set message intervals excessively long or short.

--
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

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

---

From: Henning Rogge <[email-masked]>
Date: Fri, 22 Aug 2014 08:52:02 +0200

On Thu, Aug 21, 2014 at 7:24 PM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> 3.1 could (as Henning might well point out) say that while the messages and protocol instantiations are separate, the message could share a packet.
Isn't this the same as message aggregation of OLSRv2 and NHDP?
Separate protocol instances, but can share a common RFC5444 packet? Of
course some protocols (as NHDP) have some mandatory constraints for
the packet level (e.g. IP addresses with same address length as in the
message), but thats a protocol specific thing. OLSRv2 RFC5444 messages
have no constraints on the IP address type of the surrounding packet.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 22 Aug 2014 08:46:58 +0100

No, not quite the same. 5444 explicitly discusses separate protocols. It doesn't explicitly discuss address lengths. The 5444 model assumes that all HELLO messages are sent to a single entity, regardless of address type. (It doesn't say regardless of address type, it just doesn't mention it.) That would be NHDP of course. But the NHDP description is of a protocol that has a certain type of address. I don't recall if it explicitly says drop HELLO messages with wrong address length or not.

There's nothing actually specified anywhere which describes a process something like 5444 gets HELLO, sends to NHDP. NHDP looks at address length and sends to NHDP/IPv4 or NHDP/IPv6 for address lengths 4 or 16 (and drops HELLO messages with other lengths?). Here NHPD/IPv4 and NHDP/IPv6 are separate instantiations of 6130. (And ditto for OLSRv2.) Of course that's a reasonably obvious approach, just not explicitly specified anywhere,because 5444 can say it's up to the protocol, and the protocol can say it's really a multiplexing thing.

There is an alternative to multiplexing, mapping addresses. That is a valid alternative model. For example a network a.b.c.0/24 could be designed assuming everyone knows a.b.c and then uses 1 octet addresses, saving even on address compression. I'm not sure if that's technically allowed or not, but it would work (though not, I suspect, in most implementations if the out of band compression is optional).

I'm not suggesting this is a major issue, it's mostly a technicality, which I think is how I characterised it in text cut from the quote below. (I don't have my posting to hand here.)

And the comment that messages have no constraints on the IP address type of the surrounding packet is true for 5444. It's not true for NHDP, which uses the IP datagram source address. That's actually an issue that a dual stack approach needs to cover.

On 22 Aug 2014, at 07:52, Henning Rogge wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Henning Rogge <[email-masked]>
Date: Fri, 22 Aug 2014 10:05:21 +0200

On 08/22/2014 09:46 AM, Christopher Dearlove wrote:
> No, not quite the same. 5444 explicitly discusses separate protocols.
> It doesn't explicitly discuss address lengths. The 5444 model assumes
> that all HELLO messages are sent to a single entity, regardless of
> address type. (It doesn't say regardless of address type, it just
> doesn't mention it.) That would be NHDP of course. But the NHDP
> description is of a protocol that has a certain type of address. I
> don't recall if it explicitly says drop HELLO messages with wrong
> address length or not.

http://tools.ietf.org/html/rfc6130#section-12.1

A received HELLO message is invalid for processing by this router if any
of the following conditions are true:

o  The address length as specified in the Message Header is not equal
   to the length of the addresses used by this router.

> There's nothing actually specified anywhere which describes a process
> something like 5444 gets HELLO, sends to NHDP. NHDP looks at address
> length and sends to NHDP/IPv4 or NHDP/IPv6 for address lengths 4 or
> 16 (and drops HELLO messages with other lengths?). Here NHPD/IPv4 and
> NHDP/IPv6 are separate instantiations of 6130. (And ditto for
> OLSRv2.) Of course that's a reasonably obvious approach, just not
> explicitly specified anywhere,because 5444 can say it's up to the
> protocol, and the protocol can say it's really a multiplexing thing.

You could argue that if you want to do a dualstack thing, you just need
a second level of multiplexer.

> And the comment that messages have no constraints on the IP address
> type of the surrounding packet is true for 5444. It's not true for
> NHDP, which uses the IP datagram source address. That's actually an
> issue that a dual stack approach needs to cover.

My draft already covers this, it only allows messages with a hop-limit
larger than one to be put into a UDP/RFC-5444 packet with a different
address length.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 27 Aug 2014 15:38:59 -0700

Henning, Chris,

I am currently working on Chris' review. Can you propose a sentence
for the mgmt draft that reflects this accurately?

> 3.1 could (as Henning might well point out) say that while the messages and protocol instantiations are separate, the message could share a packet.  Though there are some implications of saying so…

How about something like:

OLD
In particular, all routers in the same MANET topology must be
pre-configured to use the same IP address family (IPv4 or IPv6). In a
single OLSRv2 topology, it is not possible to mix IPv4 and IPv6
addresses, notably because [RFC5444] messages can contain either IPv4
*or* IPv6 addresses, but not both at the same time. It is, however,
possible to run two instances of OLSRv2, one instance for IPv4 and
another one for IPv6, within the same network.

NEW
In particular, all routers in the same MANET topology must be
pre-configured to use the same IP address family (IPv4 or IPv6). In a
single OLSRv2 topology, it is not possible to mix IPv4 and IPv6
addresses, notably because [RFC5444] messages can contain either IPv4
*or* IPv6 addresses, but not both at the same time. It is, however,
possible to run two instances of OLSRv2, one instance for IPv4 and
another one for IPv6, within the same network.
In general, [RFC5444] packets may contain messages with different
address lengths; however, some protocols using [RFC5444] may constrain
this further: For example, NHDP may use the IP source address of the
packet containing a HELLO message as originator address.

Thoughts?

Regards
Ulrich

---

From: Henning Rogge <[email-masked]>
Date: Thu, 28 Aug 2014 08:30:00 +0200

> packet containing a HELLO message as originator address.

Sounds good to me.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 28 Aug 2014 08:47:14 +0000

The important thing I think is to steer a middle course. It wouldn't be right to say just IPv4 or IPv6 is possible, because there is the possibility of both. But on the other hand this document is about current normal practice, which doesn't do that, so I wouldn't go into too many details, which I think here might be a bit distracting.

(And there's a colon with a following capital letter that isn't right.)

[email-masked] | http://www.baesystems.com

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Ulrich Herberg
Sent: 27 August 2014 23:39
To: Henning Rogge; [email-masked]
Subject: Re: [manet] draft-ietf-manet-olsrv2-management-snapshot-02

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

Henning, Chris,

I am currently working on Chris' review. Can you propose a sentence for the mgmt draft that reflects this accurately?

OLD
In particular, all routers in the same MANET topology must be pre-configured to use the same IP address family (IPv4 or IPv6). In a single OLSRv2 topology, it is not possible to mix IPv4 and IPv6 addresses, notably because [RFC5444] messages can contain either IPv4
*or* IPv6 addresses, but not both at the same time. It is, however, possible to run two instances of OLSRv2, one instance for IPv4 and another one for IPv6, within the same network.

NEW
In particular, all routers in the same MANET topology must be pre-configured to use the same IP address family (IPv4 or IPv6). In a single OLSRv2 topology, it is not possible to mix IPv4 and IPv6 addresses, notably because [RFC5444] messages can contain either IPv4
*or* IPv6 addresses, but not both at the same time. It is, however, possible to run two instances of OLSRv2, one instance for IPv4 and another one for IPv6, within the same network.
In general, [RFC5444] packets may contain messages with different address lengths; however, some protocols using [RFC5444] may constrain this further: For example, NHDP may use the IP source address of the packet containing a HELLO message as originator address.

Thoughts?

Regards
Ulrich

On Fri, Aug 22, 2014 at 1:05 AM, Henning Rogge <[email-masked]> wrote:
> A received HELLO message is invalid for processing by this router if 
> any of the following conditions are true:
>
> You could argue that if you want to do a dualstack thing, you just 
> need a second level of multiplexer.
>
> Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, 
> Germany

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 28 Aug 2014 12:21:08 -0700

Okay, that makes sense. We will revise the text accordingly.

Thanks!
Ulrich