Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

["Dearlove, Christopher (UK)" <[e-mail]>]

As has been pointed out to me, some implementations don’t do this. If you are building an implementation in a constrained environment, you can build a constrained implementation. And some people have.

So no, it’s not appropriate to specify an independent parser, or require one. Rather you need to design so that when people do, it can be efficient. Which is what we have been doing.

Or in other words, I don’t think this sort of change is appropriate. Quite the contrary.

The key point is that what’s mandated is a multiplexer and a format. But not an independent parser.

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

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

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: Stan Ratliff [mailto:[e-mail]]
Sent: 18 April 2016 14:09
To: Dearlove, Christopher (UK)
Cc: Christopher Dearlove; [e-mail]; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03


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


On Mon, Apr 18, 2016 at 4:52 AM, Dearlove, Christopher (UK) <[e-mail]<mailto:[e-mail]>> wrote:
I don’t believe we can or should suggest an implementation. That’s not what the IETF does, and it would be a hard, probably impossible, sell, to the IESG. That the obvious implementation employs an independent parser is already said - it may be appropriate to strengthen the words, but this second I’m not sure if that’s needed (not got time to check current wording).

(Again, with my Working Group Participant hat on) -

I don't mean to suggest an implementation. At least to me, this is an architecture (that of an independent parser, with a reliable communications mechanism to said parser, that deals with logical messages instead of packets. Is sequencing guaranteed? I'm not sure, to be honest. But once the independent parser is assumed, engineers also MUST assume that the transport (and it's the transport for control plane traffic, but not for data plane traffic), is "owned" by the independent parser.

Which leads me to the other point I'm trying to make (perhaps badly):  Abstracting the transport away from the control plane *can* effect protocol design.

I believe both of these points should be addressed in the usage document.

Regards,
Stan



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

T:  [phone]<tel:%2B44%20%280%291245%20242194>  |  E: [e-mail]<mailto:[e-mail]>

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: manet [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Stan Ratliff
Sent: 16 April 2016 19:09
To: Christopher Dearlove
Cc: [e-mail]<mailto:[e-mail]>; Christopher Dearlove
Subject: Re: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03


*** 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>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



On Fri, Apr 15, 2016 at 3:27 PM, Christopher Dearlove <[e-mail]<mailto:[e-mail]>> wrote:
I don't understand what you mean by the concept of "fields the protocol can and can't touch".

CAVEAT: I am speaking here as a Working Group participant. With that understood:


TTL is a great example, since that discussion blew the mailing list up a few months ago. I'm *not* saying manipulating TTL is a good thing for a protocol to try - in truth, I think it's pretty "hacky". But the notion was floated, and in the context of that discussion, it may will have worked. The opposition on-list was fast, and pretty forceful.
I've said before - 5444, especially with the multiplexer, changes the relationship between a routing protocol and an interface. I think the document should have some type of "overview" section which discusses these differences, in order to frame the issue for someone coming along who hasn't been a part of the 5444 mail discussion.
I'm talking about the type of overview that goes something like this:
"Use of RFC 5444 with the multiplexer feature imposes design requirements on the protocol. The actual transport mechanism is abstracted from the protocol. For example, routing protocols are not aware of precisely when a message is sent. A good example of operation in this model is [BGP], utilizing the [TCP] transport. This is opposed to a protocol such as [OSPF], which is capable of sending traffic with its own IP type. Since the transport is abstracted, protocols are not presented with "packets", and are not capable of manipulating data items in packet headers (e.g. data items at the IP and/or MAC layers)."

As Lou Berger put it to me in the context of DLEP - "You want an engineer to be able to pick up this document, with no prior exposure to the topic, and code an interoperable implementation."  I think this type of an overview, setting basic ground rules, would help.
I've also contended for a while now that 5444, with the mux, effectively forces an architecture on implementers - in the Linux world, that architecture is a 5444 parser as an independent process, with IPC mechanisms to the routing protocol(s) it is servicing. The 5444 parser itself "owns" the transport (the socket). The usage document *strongly infers* that. I believe we should concretely state it, so we don't have to answer the question over and over again.
Regards,
Stan



When a protocol creates a message from scratch it's not constrained in any way I'd describe in such terms. So I assume you mean when it receives a message and then sends a similar message.

There are two cases there. Unchanged (with the special exceptions for hop count and limit) and not unchanged. The former is better, and there's really nothing more to say.

So let's consider the latter. Really it's not the same message, it's a brand new message. That's a useful way to look at it from a security perspective, because it tells you that end to end authentication isn't going to work. And what are the restrictions on brand new messages? The same as on any new message.

OK, you might say, true but does that mean I can add this, remove that, change the hop data? Yes. But is that a good idea? No. But maybe you are forced into it. But that it's inherently not good suggests the corollary that if you must, do the minimum and make it trackable. But that's not a 5444 requirement, just good practice. It does break 7182 message ICVs, so don't use them.

We could, hypothetically, have someone create an extension or alternative to 7182 that defined aggregated signatures. Then we'd have rules on what you could change. But that would belong there. If you think those would be good, then again you would want make minimal changes, and mainly only of certain types. What types? There I can't help you as I don't have a candidate.

The summary? Don't change if you don't have to. That's recommended. If you must change you're on your own (with the same restrictions as new messages). Advice like "as little as possible" is good, but that's not actually 5444 advice. And don't use 7182 message ICVs.

--
Christopher Dearlove
[e-mail]<mailto:[e-mail]> (iPhone)
[e-mail]<mailto:[e-mail]> (home)

On 15 Apr 2016, at 19:37, Stan Ratliff <[e-mail]<mailto:[e-mail]>> wrote:
My main concern addressed inline...


On Fri, Apr 15, 2016 at 1:49 PM, Christopher Dearlove <[e-mail]<mailto:[e-mail]>> wrote:
A few immediate comments inline below.

--
Christopher Dearlove
[e-mail]<mailto:[e-mail]> (iPhone)
[e-mail]<mailto:[e-mail]> (home)

On 15 Apr 2016, at 15:18, Lotte Steenbrink <[e-mail]<mailto:[e-mail]>> wrote:
Hi all,

sparked by the recently started WGLC, I’ve reviewed the current revision of the draft. I’d like to offer the working group my perspective as someone who doesn’t have decades of protocol and/or packet format design under their belt (i.e. some things might not be obvious to me that are obvious to others), but also as someone who has worked with RFC 5444 when implementing a routing protocol (AODVv2), updating the packet format of a routing protocol (AODVv2 again) and (partially) implementing my own RFC5444 builder/parser.

Overall, I think the document is easy to read and follow. To me, it contains valuable information and guidance and in some cases prevents people from shooting themselves in the foot.
I’m really happy this document exists and I’d like it to move forward soon, but I do feel that it is still lacking in some areas, which is why I was a bit surprised to see it go to Last Call all of a sudden.

Not really. The authors had said what they intended to say, no one was commenting, time for WGLC.

First, some nitpicks and comments:

* from 1.2.1<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-1.2.1>. Packet/Message Format:


      […] a packet

      transmission following a successful packet reception is by design

      of a new packet that may include all, some, or none of the

      received messages [...]

I’m not a native speaker, but that „of“ seems out of place...

I am a native speaker, and no, it's not. Some would repeat it after each of all, some and none, and I might sometimes. But it really doesn't matter which of the two styles we pick, the RFC Editor may well change to the other.

* Regarding 4.2<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.2>. Packets and Messages:
this section talks a lot about how the multiplexer operates, so I think it’d be helpful if its title reflected that.

I'm of two opinions on that. On the one hand it is, as its title suggests, about the packet and message level, as opposed to lower levels, and its title contrasts with that if 4.3 for that reason. On the other hand you are right, it does have much about the multiplexer. A title covering all three woukd start getting cumbersome. Will take this one away to think about.

* from 4.4<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.4>. Addresses Require Attributes:


   An unmodified extension to NHDP would ignore such addresses,

   as required, as it does not support that specialized purpose.

At first glance, (to me) this reads as „All addresses that are associated with an unknown TLV are ignored“, which is obviously nonsense (but quite panic-inducing :D). I’d propose to reword it to something along the lines of

   An unmodified extension to NHDP would not consider this

   address to be of a neighbor, as it is lacking a LINK_STATUS

   or OTHER_NEIGHB TLV.

I take your point, but I think that if the address ends up with no relevant associated TLVs then it is ignored is also a point. I dare say we can wordsmith something.

Also, I don’t quite get where you’re going with the last paragraph of that section (“These restrictions do not, however, mean that added information is

   completely ignored for purposes of the base protocol.”)...

Read on, the rest of the paragraph describes the case where not. But we might telegraph that better in the opening sentence.

* regarding the maps in 4.5<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.5>. Information Representation:
I’m afraid I just don’t really understand the purpose of this section and the mapping notation. I’m assuming that the maps are supposed to offer a way of describing how a TLV relates to a message or an address?
If so, why does it only mention extension types, but not the basis types?

It says extended types, meaning the combination of the two. But full type would be better, as almost defined in 5444. In fact I think we should add a comment to the notation section. (5444 uses a symbolic name rather than the phrase.)

Or is it supposed to be used something like this:

BASE_TLV

Message:
(base_tlv_extension_type_1) -> (2 octets, "value a when condition x is met")
(base_tlv_extension_type_2) -> (2 octets, "value b when condition y is met")

? Also, I don’t quite get how this would be used in future protocol specifications? Or aid in implementing RFC5444 parsers?
An example or a clarification would be very helpful.

It's a way of looking at things. But not the only one, it goes on to discuss variants. I think it mostly comes under heading of if useful use it, if not skip it. We'll take another look, but I don't think this will ever be elementary.

* regarding 4.6<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-4.6>. TLVs:
In general, it’s not clear everywhere in the section whether you’re talking to RFC5444 parser/builder implementors or protocol designers.


   A protocol SHOULD use an efficient

   representation, but this is a quality of implementation issue.

I’m not sure where you’re going with the last part of that sentence? I’d reword it to something like „A protocol SHOULD use an efficient representation, avoiding unnecessarily verbose use of TLVs and extension types. However, the final arrangement in a message- or addressTLV block is  a quality of implementation issue“ (in case that’s what you meant).

No, you're considering the protocol design. This is considering the protocol object that implements the protocol. There isn't a one to one mapping from information to representation, it's up to the implementation to do it efficiently. Different implementations of the same protocol specification may do better or worse here. (Trivial case, an implementation could choose to never compress addresses. Bad idea, but legal.)

And then:


   A

   protocol MUST recognize any permitted representation of the

   information; even if it chooses to (for example) only use multivalue

   TLVs, it MUST recognize single value TLVs (and vice versa).

… I thought protocols weren’t supposed to specify whether a TLV is arranged (for example) as a multivalue TLV?!

Implementation again, not design.

And so, since a protocol shouldn't be concerned with multivalue TLVs and the like, wouldn’t it be the *RFC5444 implementation* that MUST recognize any permitted representation?

You're assuming that there is an RFC 5444 implementation. That's the same way to work if you plan to implement more than one protocol. But nothing says you have to do it that way. The architecture defined by 5498 admits of the multiplexer and protocols, and thus these are rules on the protocol. If protocols delegate all their common work to something (parser/creator) then it inherits those restrictions, but that's not defined, and we can't assume it.

Or is this paragraph really just a complicated way of saying „as a protocol designer, make sure to not specify/rely on things like (for example) multivalue TLVs, since your messages have to work with *any* representation“? If so, I think that should be done in a less complicated fashion (see below).

* regarding 5<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-5>. Structure:
Since this section talks a lot about flags, it’d be nice if its title represented that. Maybe consider renaming it to „Structure and Flags“ or so?

I mostly don't agree. Structure is the subject, flags are a detail.

* from 6.1<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.1>. Address Block Compression:


   Compression of addresses in an Address Block considers addresses to

   consist of a Head, a Mid, and a Tail, where all addresses in an

   Address Block have the same Head and Tail, but different Mids.


I’d find this sentence easier to read if it started with “Compression of addresses in an Address Block is possible when addresses consist of a Head, a Mid […]”.

No. That's missing the point and misleading. Addresses are always considered to have the head/mid/tail format. Compression is possible if either the head or tail (or both) is non-empty.

* from 6.1<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.1>. Address Block Compression:



   Putting addresses into a message efficiently also has to include:


Why „has to“? I’d think that would be a „may“. Multiple Adress Blocks and/or reordering don’t increase efficiency in all possible cases...

I think that's the wrong change. Rather "include" should be "consider".

* from 6.2<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.2>. TLVs:

      [...] This is even possible if the MPR TLV specified in

      OLSRv2 [RFC7181<https://tools.ietf.org/html/rfc7181>] is added; but it is not possible, in general, if

      the LINK_METRIC TLV is also added.

Why is it not possible for the latter? If that could be explained/hinted at in a half sentence, I think it’d be helpful information to have in the draft.

That's very hard, and not just because it's a negative. It's really an observation that motivates the duscussion. A half sentence would I think confuse more than it enlightens (it's because you have too many constraints to satisfy at once - I doubt that helped).


      In a typical case where a

      LINK_STATUS TLV uses only the Values HEARD and SYMMETRIC, with

      enough addresses, sorted appropriately, two single value TLVs can

      be more efficient than one multivalue TLV.

Same thing: why?

Here I think this should be obvious to anyone who has looked at 5444.

* regarding the second paragraph from 6.3<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.3>. TLV Values, i.e.



   This approach was specified in [RFC7188<https://tools.ietf.org/html/rfc7188>], and required for protocols

   that extend [RFC6130<https://tools.ietf.org/html/rfc6130>] and [RFC7181<https://tools.ietf.org/html/rfc7181>].  It is here RECOMMENDED that

   this approach is followed when defining any Address Block TLV that

   may be used by a protocol using [RFC5444<https://tools.ietf.org/html/rfc5444>].

The term „this approach“ confused me, since I initially  thought it meant „the approach is to use UNSPECIFIED in a way that makes sense“ rather than „the approach is to use UNSPECIFIED“. Maybe that could be reworded to something along the lines of
The UNSPECIFIED TLV and its usage was specified in [RFC7188]…
?

No. There is no UNSPECIFIED TLV. There is a recommendation to include an UNSPECIFIED value in a TLV. But really, we've described this once in 7188, it's there to read.

* regarding 6.3<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.3>. TLV Values:
The second paragraph is a bit confusing and seems to explaing roghly the same things as the fourth paragraphs. I’d propose to merge the second into the fourth.

I'm not sure I exactly agree, but the ordering in that section could be improved.

* from 6.4<https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-03#section-6.4>. Automation:


   The possible gain depends on the efficiency

   of the original message creation,

the term „the original message creation“ seems a bit ambiguous– does this refer to the message as created by an RFC5444 message builder implementation?

Yes.

Additionally, I'm concerned about two things that *aren’t* in the draft:

*  Some of the AODVv2 co-authors and me have asked for a list of „as a protocol, you can set all of these fields of a message, but please leave the rest alone“, which would’ve saved us many hours of discussions (and Henning a lot of time spent explaining these things…). These requests have been met with a refusal to specify a concrete API, as such an effort is dependent on outside factors such as programming language or software architecture. I agree with this notion, but a programming-language dependent API is not what we’ve asked for. I’ve tried to supply a sketch of what I did ask for in [1], but unfortunately I didn’t get an answer (and as far as I can see it, the draft wasn’t changed either). I still think that such a list, in whatever form, would be very helpful for future Internet-Draft authors and I also think this request is in accordance with the intentions stated in 1.1 History and Purpose, and I think it should be included in the document.

No. There are many reasons why we're just not touching this one.

One is that language independence is a mirage. How you go about things is completely different in, for example an object oriented language than one that isn't. Section 4.5 shows that there are quite different ways of doing things even given a decision to use a map approach, and there are other approaches than that. It would be wrong and beyond our competence to suggest one of these as "best". There's reasons the IETF doesn't do this, and that's one.

Plus, frankly, the work it would take is beyond what we choose to spend.


<Speaking as a WG Participant>

I'm confused (which is an altogether too common occurrence these days). I get that we don't want to specify an API. But I think the discussion about fields a protocol can and can't touch in a messages is a good thing - and it's one spot where I, too, find the document wanting.

To paraphrase something I've said before, I believe that RFC 5444 changes the relationship that a routing protocol has with an "interface". I'm not commenting on whether or not that's a good thing, or a bad thing - just that it does change the relationship. This change has been at the root of some of the long-running discussions as to whether protocols under development were RFC 5444 compliant or not. The goal of this document being to eliminate (it's a goal, probably not reachable) those discussions, I'd like to see that information in the document in some form.

I'm interested in seeing this document progress, and eventually be published. I think it will help future protocol designers to better use RFC 5444. But I would like to see *something* along the lines of what Lotte is requesting, as I think it will improve the doc.

Regards,
Stan



* As the exact rules for using/setting the hop count & hop-limit fields are currently being discussed w/ regard to AODVv2 in another thread [2]– should a definitive answer to that question be part of 5444-usage?

You don't want that. Because if we did specify that you'd find yourself more constrained than you want to be. There is a design intent described in 5444, but it assumes immutable messages. Which you don't want. Really, we're doing you a favour by not imposing on you.

Best regards,
Lotte

[1] https://www.ietf.org/mail-archive/web/manet/current/msg18082.html
[2] https://www.ietf.org/mail-archive/web/manet/current/msg18674.html


Am 06.04.2016 um 19:14 schrieb Justin Dean <[e-mail]<mailto:[e-mail]>>:

The chairs agree that a 3 week WGLC is appropriate.  Everyone please read the draft early and get comments in early so that they can be addressed within the last call period.

Justin

On Wed, Apr 6, 2016 at 7:40 AM, Dearlove, Christopher (UK) <[e-mail]<mailto:[e-mail]>> wrote:
Obviously +1 to the request for WGLC.

With regard to what's changed, technically the only significant thing is to make it clear that if a protocol delivers a message to the multiplexer, the multiplexer must pass it on unchanged to the protocol (another instance of, at another router) unchanged. Without that nothing that the protocol itself chooses to do with regard to security makes sense. Though the protocol can alternatively let the multiplexer do the security, 7182 can be implemented in either way. This isn't really new, but it wasn't formally spelled out. It's presented as part of spelling out multiplexer rules more carefully.

But what about message optimisation? That's a function of constructing a 5444 message, not the multiplexer, and is down to that 5444 includes two things - packet/message structure (and implicitly, and in pretty much any implementation I would expect to see, a parser and builder for that structure) and the multiplexer. So we took the opportunity to separate out more clearly a discussion of the two, which we think will be helpful.

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

T:  [phone]<tel:%2B44%20%280%291245%20242194>  |  E: [e-mail]<mailto:[e-mail]>

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

-----Original Message-----
From: manet [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Ulrich Herberg
Sent: 05 April 2016 20:08
To: [e-mail]<mailto:[e-mail]>
Subject: [manet] WGLC request for draft-ietf-manet-rfc5444-usage-03

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

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.


Hi,

As you have seen, we have submitted a new revision of 5444-usage. The authors feel comfortable that we have addressed all issues by this version, and would like to ask the WG chairs to issue a WGLC on this document. While it is a fairly short document, given that it is IETF week for some, we'd suggest that a 3-4 week WGLC would be appropriate.

Best regards
Ulrich

_______________________________________________
manet mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
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.
********************************************************************

_______________________________________________
manet mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/manet