Re: [manet] Not just 5498 but also 5444 compliance (was: Re: #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove))

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

I think we’ve said something like that before.

But just to make Thomas’s workload even greater, there are many details of 5444, NHDP and OLSRV2 that the authors would like to provide rationale material for. We’ve done it once, for metrics. But it really is something that’s hard to find time to do, because it’s just a good idea, rather than being essential.

--
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: [phone] |  Fax: [phone]
[e-mail]<mailto:[e-mail]> | 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

From: Thomas Heide Clausen [mailto:[e-mail]]
Sent: 22 July 2014 14:52
To: Dearlove, Christopher (UK)
Cc: [e-mail]; manet-ads; [e-mail]
Subject: Re: [manet] Not just 5498 but also 5444 compliance (was: Re: #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove))


*** 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 22 Jul 2014, at 15:45 , Dearlove, Christopher (UK) <[e-mail]<mailto:[e-mail]>> wrote:

Actually, I think there has been some improvement here, but could be improved further. This is at the level of comment I didn’t attempt to make, I concentrated on what I considered the most major issues.

Improvement, I agree, but still *quite* far from to the point where it’s correct.

IIRC, two TLVs are suggested, one to say “this is A”, one to say “this is B”. It’s assumed there are two addresses, and the one that’s not A is B, and vice versal.

Better is to have a single TLV with a  value for A or B. Why? First, it avoids wasting a TLV code point. Second, you can flag A and B with a single multivalue TLV more efficiently than marking A and B. And it’s a good idea to mark A and B, because that way you can add additional addresses in an extension, without introducing any problems as to which is A or B with a single TLV. In addition, the practice we introduced in TLV extensions of having a null value (255 UNSPECIFIED is what we used) can help there as well.

Yes, and while important, the above is a design detail that is relatively easy to hammer out, when all else is completed.


One of those things the authors of 5444 etc. would like to do – when they can find some extra hours in a week – is to set out this sort of good practice for 5444 that has been found to be valuable. In this case we have the two principles of (a) always attack a TLV to indicate information, as just doing so from a non-TLVed address precludes various extensions, and (b) when attaching information, null values are good – T:LV extensions discusses why, a lot comes down to that you can’t order for more than one or two TLVs at once.

Yes, and with the caveat that one of the 5444 authors is trying to find some hours this week for that, so that may be forthcoming soon.

(See, Chris, now you made me go public with this, so I’m kinda on the hook for producing something….)

Thomas



--
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: [phone] |  Fax: [phone]
[e-mail]<mailto:[e-mail]> | http://www.baesystems.com<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

From: Thomas Heide Clausen [mailto:[e-mail]]
Sent: 22 July 2014 14:08
To: Dearlove, Christopher (UK)
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; manet-ads
Subject: Not just 5498 but also 5444 compliance (was: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove))


*** 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>.
I am still, with reference to this document, dismayed to see that there remain abundant references to positional information in address blocks in RFC5444 messages.

As has been pointed out numerous times, this is inappropriate, positional information cannot be assumed assured and preserved by generic 5444 message generation and parsing code. The first instance of this offense is in Table 1 ...

This has been requested fixed for years now. When will it be fixed?


On 22 Jul 2014, at 14:24 , Dearlove, Christopher (UK) <[e-mail]<mailto:[e-mail]>> wrote:

RFC5444 describes a multiplexing process. It is not required purely in its own terms. But RFC 5498 make it mandatory for any protocol using the port/protocol allocated by that RFC. And the WG has agreed that all routing protocols developed have to be able (at least) to use that port/protocol.

--
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: [phone] |  Fax: [phone]
[e-mail]<mailto:[e-mail]> | http://www.baesystems.com<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

From: manet [mailto:[e-mail]] On Behalf Of Abdussalam Baryun
Sent: 22 July 2014 12:02
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)


*** 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>.
IMHO The problem is that RFC5444 still does not have a multiplexing standard in IETF. The way of multiplexing is still just implemented by OLSRv2 experts but I dont find any standard for multiplexing yet. The RFC5498 is not for multipexing as I understand it. We already discussed once that multiplexing is not specified for all RFC5444 formats because it is general format but RFC5498 is not general.

If I am wrong please point me to an RFC.
AB
On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker <[e-mail]<mailto:[e-mail]>> wrote:
#45: RFC 5498 non-compliance (submitted for Chris Dearlove)

 The document is completely noncompliant with the RFC 5444 multiplexing
 mechanism, mandated by RFC 5498 (on the manet port/protocol). It does
 many things that are not within its competence.

--
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-manet-
  [e-mail]<mailto:[e-mail]>  |  [e-mail]<mailto:[e-mail]>
     Type:  defect       |     Status:  new
 Priority:  minor        |  Milestone:
Component:  aodvv2       |    Version:
 Severity:  Active WG    |   Keywords:  RFC 5498
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <https://tools.ietf.org/wg/manet/trac/ticket/45>
manet <http://tools.ietf.org/manet/>

_______________________________________________
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