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

[Justin Dean <[e-mail]>]

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]> 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]  |  *E: *[e-mail]
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
> Baddow, Chelmsford, Essex CM2 8HN.
> 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: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.
> ********************************************************************
>