Re: [OSPF] IETF 67 OSPF WG Meeting minutes - Correct file appended

["Phil Cowburn" <[e-mail]>]

Acee,

> Presentation Michael Barnes : Crypto alg reqmts for OSPFv2
>
>    Some discussion on list already
>
>    Crypto - only md5 to date, can be attacked, some want stronger algs
>         perhaps should specify these
>
>    How - 2328 can add other algs w/o too much problem

Yes it does, but debugging would be a nightmare! :-)

Let me not trigger a discussion again, i am ok with using the existing
type code!

>
>    This draft - new algorithms should be used and won't change
>    proto fields, there is key-id field which can has an associated
>    algorithm as a property.
>
>    Adding crypto terms- SA's - will carry key/alg choice, fairly
>    straight forward approach - should not cause backwards compatibility
>    because no change to OSPF proto fields - it's mis-config if one peers
>    has a different algorithm.
>
>    Acee: IPSec for v3, once done, lacks replay and key dist issues
>    on lan - w/v2 these problems are solved mainly (seq#>=, not
>    monotonic incr). Vishwas present requirements in Paris in both
>    OSPF and RPSEC WGs.
>
>    Sandy Murphy, Sparta : what is manditory to implement?
>    Michael - Separate doc will discuss what is req'd (ala ISIS approach)
>
> Presentation: Manav Bhatia - Crypto Requirements Document
>
>    NULL, MS5, sha1, cryptographic - refs in this doc
>    more algorithms keep coming eg des was once must, now is should ot
>
>    What doc must, should, - running doc as algorithms come and go
>    uses 2119 terms should+ = should may become must
>
>    See slides and draft for specific requirements.
>
>    Acee: "should not" wording is problematic for NULL and other
>    existing requirements.
>
>    Russ white: shold may become a must vs. should+ (better to say
>         what is meant)

I dont see any show stopper comments, so what is the status of the
auth drafts? There was a discussion on these drafts some time back and
the consensus was that the drafts would not be changed and we would
reuse the existing type code for additional authentication types.

If there are no further comments then should these be taken up as a new items?

>
> Presentation Lou Berger: berger-ospf-rfc2370bis followon to ietf66 - opaque
>    LSA across areas - problem w/validation - so instead rev'd 2370

..

>
>    Acee wanted MAY or Should added
>    Acee: when we add new info to TE LSAs - scalability issues -
>          give priority to base ospf LSA over the opaque LSAs.
>    Lou: We should take to list whether MAY or SHOULD should be in
>         the final text.

SHOULD sounds too strong to me. This is an implementation specific
issue and not all implementations may be able to prioritize OSPF pkts.
In view of this, a MAY should be sufficient as a recommendation from
the WG. Lets not word it any stronger than this.

>
>    Acee: Will validate on list that this is to become a WG document.

I am in favor of this.

Phil

_______________________________________________
OSPF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf