Re: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items

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

Still strongly disagree with some of what you say. The multiplexer MUST NOT modify messages as far as the protocol can tell, no flag as to whether it may, that’s just absolutely horrible. But there is a get out of gaol free card - it could modify a message (e.g. add a TLV, such as an ICV) then revert it (remove the TLV) before the protocol sees it. The next 5444 usage draft will say this.

A protocol in general SHOULD NOT, but MAY, modify messages. OLSRv2 MUST NOT modify messages.

--
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: Justin Dean [mailto:[e-mail]]
Sent: 23 March 2016 12:40
To: Dearlove, Christopher (UK)
Cc: [e-mail]; Thomas Heide Clausen ([e-mail])
Subject: Re: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items


*** 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>.
RFC 7182 is mandatory to RFC 7181.  In violent agreement.  OLSRv2 MUST NOT do that.  5444 doesn't generate/forward messages though 7181 does.  Clearly there should be a way for a process sitting on the multiplexer to tell it that a message is immutable.  But in other cases a message does get change/added to (e.g. 6121 (SMF) tlvs attached to 6130 (NHDP) hello messages).  In the end we all seem to agree end-to-end security is a problem currently for AODVv2.
Justin

On Wed, Mar 23, 2016 at 8:29 AM, Dearlove, Christopher (UK) <[e-mail]<mailto:[e-mail]>> wrote:
I’ve put the MANET list back on distribution.

As Thomas has pointed out to me, RFC 7182 is mandatory to implement as specified in RFC 7181. Thus “without ICVs” is not an option, and anything that breaks 7182 breaks compliance with 7181. And changing a message breaks 7181, in addition to it being directly indicated that messages are forwarded unchanged (hop count/limit aside).

Or in other words, OLSRv2 MUST NOT do this, and 5444 multiplexer MUST NOT change messages (as visible from protocol). I have an updated 5444 usage draft that makes this clearer for the multiplexer, waiting on co-authors to review.

--
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: Justin Dean [mailto:[e-mail]<mailto:[e-mail]>]
Sent: 23 March 2016 12:23
To: Dearlove, Christopher (UK)
Subject: Re: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items


*** 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>.
CMD> I think this comes under the heading of “not prohibited but undesirable” but also that all options I can see involve something undesirable, or worse, so this may be the least undesirable
JWD: check.

JWD> The way multiplexers work messages can get torn apart and sent back out in a different way.  My OLSRv2 with another version will likely do just that.

CMD> Absolutely not, that is a violation of OLSRv2 rules and unacceptable, because OLSRv2 specifies forwarding messages unchanged. That completely breaks use of RFC 7182 message ICVs - which might be applied by the multiplexer. Please do not even consider this.
JWD: you are correct.  ICVs disallow this behavior.  In my own code the messages are not changed because I generated them in the first place.  Without ICVs though it's quite natural.  I've personally seen three different packetbb parsers (one my own) which by default will rearrange a message if processed and regenerated  (actually caused some headache when trying to debug and getting different generated message outputs).  If there are no ICVs and it doesn't matter, but that's throwing all of end to end security out the window.  End to end security is an issue.

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