Subject: [manet] DLEP-17: Handling of unknown / unexpected messages

From: Lou Berger <[email-masked]>
Date: Wed, 9 Dec 2015 14:02:26 -0500

Authors/WG,

The current text has different processing rules for unexpected signals
and messages:

   If an unrecognized, or unexpected signal is received, or a received
   signal contains unrecognized, invalid, or disallowed duplicate data
   items, the receiving peer MUST ignore the signal.

and

   If an unrecognized, or unexpected message is received, or a received
   message contains unrecognized, invalid, or disallowed duplicate data
   items, the receiving peer MUST issue a Session Termination message
   (Section 9.7) with a Status data item (Section 10.1) containing the
   most relevant status code, and transition to the Session Termination
   state.

It seems to me that the approach of resetting a session any time
anything unexpected occurs is overly restrictive and is likely to lead
to instability and interoperability issues as implementations mature and
the protocol is extended.  (As well as add some interesting
vulnerabilities.)  It's also not clear, what real value the approach brings.

Following behavior common in other IETF protocols, and the IETF/Jon's
design maxim of "Be liberal in what you accept..."  I'd propose that
unrecognized, invalid, or disallowed duplicate data items and messages
be ignore.  Counting them and reporting them via the management plane
should also be allowed, and perhaps recommended.

Lou

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 9 Dec 2015 14:26:46 -0500

>    items, the receiving peer MUST ignore the signal.

Since "signal" refers to "The UDP messages/packets that are sent as a part
of discovery", and therefore, no Peer session exists, ignoring (and maybe
logging) is about all you can do.

> vulnerabilities.)  It's also not clear, what real value the approach

This was a compromise, after a lot of discussion. The issue is that
something the receiver doesn't understands, and therefore ignores, may be
crucial to the sender. If the receiver ignores it, and by definition does
not negatively ACK it, then the sender will wind up in a transaction
timeout... the processing there is to pull down the Peer-to-peer session.
We figured it was better for the receiver of a message not understood to go
ahead and proactively tear the session down.

Regards,
Stan

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

---

From: Lou Berger <[email-masked]>
Date: Wed, 9 Dec 2015 15:43:29 -0500

Stan,

On 12/9/2015 2:26 PM, Stan Ratliff wrote:
>
>
> On Wed, Dec 9, 2015 at 2:02 PM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Authors/WG,
>
> Since "signal" refers to "The UDP messages/packets that are sent as a
> part of discovery", and therefore, no Peer session exists, ignoring
> (and maybe logging) is about all you can do. 
>
>  
>
>
>     and
>
> something the receiver doesn't understands, and therefore ignores, may
> be crucial to the sender. If the receiver ignores it, and by
> definition does not negatively ACK it, then the sender will wind up in
> a transaction timeout... the processing there is to pull down the
> Peer-to-peer session. We figured it was better for the receiver of a
> message not understood to go ahead and proactively tear the session down. 
>

Is there any real harm in letting the transaction time out?  It seems to
me will be a constantly bouncing session with nothing working, vs having
some base level of stable capability.

Do you object to changing the behavior?

Lou

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

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 9 Dec 2015 16:01:49 -0500

Lou,

> some base level of stable capability.

First off, I have to back-track and retract what I said. It's sad when you
don't correctly remember what's in your own document... ;-)  Section 4.1,
last para states "DLEP transactions do not time out and are not
cancellable." My profound apologies for mis-stating this earlier.

> Do you object to changing the behavior?

I need to be careful about which hat I'm wearing here - speaking just as a
WG participant, and a person that's interested in DLEP, I think that the
processing rules have gotten too restrictive - basically, on any error, the
only answer is to activate the nuclear self-destruct device, and blow
everything to kingdom-come. Just in my little-ole opinion, that's a tad
harsh...

As I mentioned earlier, this text was the result of much (too much)
haggling, talking, and discussing of options. I feel like I was pretty much
"in the rough" when the text was adopted; there are others on the list that
I hope will comment. What I believe is that:
1. An invalid or mis-understood *message* needs to be countered with
termination, since based on Section 4.1, the sender will have a transaction
"hanging out in space" that will never time out, and can't be cancelled.
2. As to invalid *Data Items*, I think the rules should be loosened -
specifically, I believe that "If an unrecognized, or unexpected message is
received, or a received message contains unrecognized, invalid, or
disallowed duplicate data items", then the receiving implementation should
negatively acknowledge, with an appropriate status Data Item/error code.

But that's just my $0.02-worth. Looking for other opinions on the list...

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 9 Dec 2015 22:21:22 +0100

> negatively acknowledge, with an appropriate status Data Item/error code.

I don't think there is a second good solution... when something goes
wrong, the endpoint (either radio or router) has no real way to know
what happened.

* Was the data stream malformed?
* Did the client mis-implement an extension (or forgot to announce one)?
* Alien Space Bats happend?

The only thing the endpoint knows that the communication coming from
the other side turned bad and cannot be trusted anymore.

The sending of the "session termination" is just nice window dressing
to give the other side a chance to quickly tear down its session data,
there is not much else to do except for dropping the session.

Henning Rogge

---

From: Lou Berger <[email-masked]>
Date: Wed, 9 Dec 2015 16:27:28 -0500

> there is not much else to do except for dropping the session.

The problem is that this "window dressing" introduces limitations on
future compatibility/partial interoperability and vulnerabilities.  It
seems to me to be an unnecessary "optimization".

Lou

---

From: Henning Rogge <[email-masked]>
Date: Wed, 9 Dec 2015 22:32:28 +0100

> seems to me to be an unnecessary "optimization".

No, it does not.

Because you have to announce all your endpoints functionality in the
first Message (Peer Init/Peer Init Ack).

If you do something the other side does not understand after this your
implementation is defective.

Henning Rogge

---

From: "A .Riley Eller" <[email-masked]>
Date: Wed, 9 Dec 2015 13:34:40 -0800

(Hi all, long time reader.)

> seems to me to be an unnecessary "optimization".

Perhaps I have lost track of the context of this thread, but isn't the
"session termination" response merely an unambiguous transfer of state in
the event of unsuccessful (and possibly partial) inter-operation? Each
party need a means to reset the other's expectation of shared context.

Riley

---

From: Lou Berger <[email-masked]>
Date: Wed, 9 Dec 2015 17:22:37 -0500

> implementation is defective.

okay, I wouldn't go this way but not my call. 

The principle of "be liberal in what you accept..." has served may
protocols well....

Lou

---

From: "MATTY, Steven" <[email-masked]>
Date: Thu, 10 Dec 2015 09:58:42 +0000

From: manet [mailto:[email-masked]] On Behalf Of Stan Ratliff

>I need to be careful about which hat I'm wearing here - speaking just as a WG participant, and a person that's
>interested in DLEP, I think that the processing rules have gotten too restrictive - basically, on any error,
>the only answer is to activate the nuclear self->destruct device, and blow everything to kingdom-come. Just in
>my little-ole opinion, that's a tad harsh...

>As I mentioned earlier, this text was the result of much (too much) haggling, talking, and discussing of
>options. I feel like I was pretty much "in the rough" when the text was adopted; there are others on the list
>that I hope will comment. What I believe is that:

>1. An invalid or mis-understood *message* needs to be countered with termination, since based on Section 4.1,
>the sender will have a transaction "hanging out in space" that will never time out, and can't be cancelled.

>2. As to invalid *Data Items*, I think the rules should be loosened - specifically, I believe that "If an
>unrecognized, or unexpected message is received, or a received message contains unrecognized, invalid, or
>disallowed duplicate data items", then the receiving >implementation should negatively acknowledge, with an
>appropriate status Data Item/error code.

>But that's just my $0.02-worth. Looking for other opinions on the list...

Well as you asked for it…

1) My inclination is towards the “Be generous in what you accept” side of things. But there is a trade-off when you
are being a friendly DLEP application that accepts any and all messages versus trying to ensure all DLEP
implementations are compliant. If you tear down the session whenever you get an invalid DLEP message then it
will become VERY obvious, VERY quickly that you are talking with a ‘bad’ implementation. However, let’s say that
this implementation on a router is no longer supported but is actually very useful in everything else it does right.

Would it be an option to introduce an [optional] NACK DLEP message type so that you can report to the sender
“Hey, you sent me this and something was up there” rather than just a silent discard?

If we were to loosen this rule, then the question would be “Under what circumstances would you terminate the session”
and it would be helpful if the DLEP draft were update to include perhaps a table summarizing such events.

If I were asked to get off the fence, I’d probably land on the side where you silently (and optionally report to your
management interface, up to your implementation really) ignore invalid or illegal DLEP messages. Even if it means
the sender of such illicit material may complain about missing ACKs, well tough on them really.

2) Invalid Data Items - I think these can certainly be loosened and I agree with responding with a NACK or suitable
equivalent.

Regards

Steve

This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space Limited disclaims any and all liability if this email transmission was virus corrupted, altered or falsified.
-o-
Emails to Airbus Defence and Space Limited may be processed, recorded and monitored outside the UK.
-o-
Airbus Defence and Space Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England

---

From: Henning Rogge <[email-masked]>
Date: Thu, 10 Dec 2015 11:05:55 +0100

On Thu, Dec 10, 2015 at 10:58 AM, MATTY, Steven <[email-masked]>
wrote:

> From: manet [mailto:[email-masked] <[email-masked]>] On
> Behalf Of Stan Ratliff
>
> 1) My inclination is towards the “Be generous in what you accept” side of
> things. But there is a trade-off when you
> this implementation on a router is no longer supported but is actually
> very useful in everything else it does right.
>

The problem is you cannot be sure that the message was not malformed if
something goes wrong... which means you don't know where to  start the next
message in the incoming TCP stream.

Henning Rogge

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Thu, 10 Dec 2015 14:02:33 +0000

Henning,

As long as the overall message length isn’t screwed up, you’d be OK. Just take that value and “step over” the next <blah> octets in the incoming TCP stream…
that said, I must admit that I don’t like the idea. If the message is that messed up, this probably is the right time for the “nuclear option”. I just think we’ve gone a bit too far with all of the data items.

Regards,
Stan

From: Henning Rogge [mailto:[email-masked]]
Sent: Thursday, December 10, 2015 5:06 AM
To: MATTY, Steven <[email-masked]>
Cc: Stan Ratliff <[email-masked]>; Lou Berger <[email-masked]>; MANET IETF <[email-masked]>; [email-masked]
Subject: Re: [manet] DLEP-17: Handling of unknown / unexpected messages

On Thu, Dec 10, 2015 at 10:58 AM, MATTY, Steven <[email-masked]<mailto:[email-masked]>> wrote:
From: manet [mailto:[email-masked]] On Behalf Of Stan Ratliff

The problem is you cannot be sure that the message was not malformed if something goes wrong... which means you don't know where to  start the next message in the incoming TCP stream.

Henning Rogge

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________