Adding support for OSPF authentication modes and encryption types
- (M) release/models/ospf/openconfig-ospf-types.yang
- (M) release/models/ospf/openconfig-ospfv2-area-interface.yang
- (M) release/models/ospf/openconfig-ospfv2.yang
Change Scope
Currently, OSPF authentication is not well-defined with only the authentication-type parameter being available and also with no defined values specified. Added a backward compatible new authentication node under OSPF interface where we can define authentication modes, simple password, and also a message-digest container to configure key, password, encryption type.
+--rw network-instances
+--rw network-instance* [name]
+--rw protocols
+--rw protocol* [identifier name]
+--rw ospfv2
+--rw areas
+--rw area* [identifier]
+--rw interfaces
+--rw interface* [id]
**+--rw authentication
+--rw config
| +--rw auth-mode? identityref
| +--rw simple-password? string
+--ro state
| +--ro auth-mode? identityref
| +--ro simple-password? string
+--rw message-digests
+--rw message-digest* [md-key-id]
+--rw md-key-id -> ../config/md-key-id
+--rw config
| +--rw md-key-id? uint8
| +--rw md-encryption? identityref
| +--rw md-password? string
+--ro state
+--ro md-key-id? uint8
+--ro md-encryption? identityref
+--ro md-password? string**
Platform Implementations
- Arista : https://www.arista.com/en/um-eos/eos-open-shortest-path-first-version-2#xx1151536
isn't a security threat if we share OSPF configured password via streaming ?
- What is auth-mode? Is it same as 'Autype' define in RFC2328? If so, I think it should be kept under "interface".
- What is md-encryption? Is it same as 'Autype' define in RFC2328? If so, above comment applies here too.
Thanks, Dona
Have you considered coverage for keychains which is supported across various implementations?
Not as of now.
- What is auth-mode? Is it same as 'Autype' define in RFC2328? If so, I think it should be kept under "interface".
- What is md-encryption? Is it same as 'Autype' define in RFC2328? If so, above comment applies here too.
Thanks, Dona
- What is auth-mode? Is it same as 'Autype' define in RFC2328? If so, I think it should be kept under "interface".
- What is md-encryption? Is it same as 'Autype' define in RFC2328? If so, above comment applies here too.
Thanks, Dona
auth-mode is same as 'Autype' but we have defined it as identity AUTH_MODE. It is added under "authentication" which is under "interface" right? md-encryption is now changed to "auth-algo" which defines the hash algorithm to be used to generate message digest.
- What is auth-mode? Is it same as 'Autype' define in RFC2328? If so, I think it should be kept under "interface".
- What is md-encryption? Is it same as 'Autype' define in RFC2328? If so, above comment applies here too.
Thanks, Dona
- What is auth-mode? Is it same as 'Autype' define in RFC2328? If so, I think it should be kept under "interface".
- What is md-encryption? Is it same as 'Autype' define in RFC2328? If so, above comment applies here too.
Thanks, Dona
auth-mode is same as 'Autype' but we have defined it as identity AUTH_MODE. It is added under "authentication" which is under "interface" right? md-encryption is now changed to "auth-algo" which defines the hash algorithm to be used to generate message digest.
"We would want to be able to configure message digest keys, simple password irrespective of mode selected." ==> Saw this comment from you. If this is the case, mode configuration should be outside of key values right? Means, Autype should reflect what is the actual Autype on the configured on the interface; not the Autype associated with the key.
- What is auth-mode? Is it same as 'Autype' define in RFC2328? If so, I think it should be kept under "interface".
- What is md-encryption? Is it same as 'Autype' define in RFC2328? If so, above comment applies here too.
Thanks, Dona
- What is auth-mode? Is it same as 'Autype' define in RFC2328? If so, I think it should be kept under "interface".
- What is md-encryption? Is it same as 'Autype' define in RFC2328? If so, above comment applies here too.
Thanks, Dona
auth-mode is same as 'Autype' but we have defined it as identity AUTH_MODE. It is added under "authentication" which is under "interface" right? md-encryption is now changed to "auth-algo" which defines the hash algorithm to be used to generate message digest.
"We would want to be able to configure message digest keys, simple password irrespective of mode selected." ==> Saw this comment from you. If this is the case, mode configuration should be outside of key values right?
+--rw network-instance* [name]
+--rw protocols
+--rw protocol* [identifier name]
+--rw ospfv2
+--rw areas
+--rw area* [identifier]
+--rw interfaces
+--rw interface* [id]
+--rw authentication
+--rw config
| +--rw auth-mode? identityref
| +--rw simple-password? oc-types:routing-password
+--ro state
| +--ro auth-mode? identityref
| +--ro simple-password? oc-types:routing-password
+--rw message-digests
+--rw message-digest* [key-id]
+--rw key-id -> ../config/key-id
+--rw config
| +--rw key-id? uint8
| +--rw auth-algo? identityref
| +--rw auth-key? oc-types:routing-password
+--ro state
+--ro key-id? uint8
+--ro auth-algo? identityref
+--ro auth-key? oc-types:routing-password
So, we can configure mode here without configuring keys right and vice-versa, all existing under "authentication" container.
- What is auth-mode? Is it same as 'Autype' define in RFC2328? If so, I think it should be kept under "interface".
- What is md-encryption? Is it same as 'Autype' define in RFC2328? If so, above comment applies here too.
Thanks, Dona
- What is auth-mode? Is it same as 'Autype' define in RFC2328? If so, I think it should be kept under "interface".
- What is md-encryption? Is it same as 'Autype' define in RFC2328? If so, above comment applies here too.
Thanks, Dona
auth-mode is same as 'Autype' but we have defined it as identity AUTH_MODE. It is added under "authentication" which is under "interface" right? md-encryption is now changed to "auth-algo" which defines the hash algorithm to be used to generate message digest.
"We would want to be able to configure message digest keys, simple password irrespective of mode selected." ==> Saw this comment from you. If this is the case, mode configuration should be outside of key values right?
+--rw network-instance* [name] +--rw protocols +--rw protocol* [identifier name] +--rw ospfv2 +--rw areas +--rw area* [identifier] +--rw interfaces +--rw interface* [id] +--rw authentication +--rw config | +--rw auth-mode? identityref | +--rw simple-password? oc-types:routing-password +--ro state | +--ro auth-mode? identityref | +--ro simple-password? oc-types:routing-password +--rw message-digests +--rw message-digest* [key-id] +--rw key-id -> ../config/key-id +--rw config | +--rw key-id? uint8 | +--rw auth-algo? identityref | +--rw auth-key? oc-types:routing-password +--ro state +--ro key-id? uint8 +--ro auth-algo? identityref +--ro auth-key? oc-types:routing-passwordSo, we can configure mode here without configuring keys right and vice-versa, all existing under "authentication" container.
Why is Autype is associated with "simple-password"? MD5 also should have an Autype of 2. As per RFC 2328: AuType Description ___________________________________________ 0 Null authentication 1 Simple password 2 Cryptographic authentication
If possible, please make the design common to all Cryptographic Authentications. Keyed-MD5 is just one among them.
/gcbrun
No major YANG version changes in commit 589800b87b9c5b3ac5de139c27720db47b8c9c45
- What is auth-mode? Is it same as 'Autype' define in RFC2328? If so, I think it should be kept under "interface".
- What is md-encryption? Is it same as 'Autype' define in RFC2328? If so, above comment applies here too.
Thanks, Dona
- What is auth-mode? Is it same as 'Autype' define in RFC2328? If so, I think it should be kept under "interface".
- What is md-encryption? Is it same as 'Autype' define in RFC2328? If so, above comment applies here too.
Thanks, Dona
auth-mode is same as 'Autype' but we have defined it as identity AUTH_MODE. It is added under "authentication" which is under "interface" right? md-encryption is now changed to "auth-algo" which defines the hash algorithm to be used to generate message digest.
"We would want to be able to configure message digest keys, simple password irrespective of mode selected." ==> Saw this comment from you. If this is the case, mode configuration should be outside of key values right?
+--rw network-instance* [name] +--rw protocols +--rw protocol* [identifier name] +--rw ospfv2 +--rw areas +--rw area* [identifier] +--rw interfaces +--rw interface* [id] +--rw authentication +--rw config | +--rw auth-mode? identityref | +--rw simple-password? oc-types:routing-password +--ro state | +--ro auth-mode? identityref | +--ro simple-password? oc-types:routing-password +--rw message-digests +--rw message-digest* [key-id] +--rw key-id -> ../config/key-id +--rw config | +--rw key-id? uint8 | +--rw auth-algo? identityref | +--rw auth-key? oc-types:routing-password +--ro state +--ro key-id? uint8 +--ro auth-algo? identityref +--ro auth-key? oc-types:routing-passwordSo, we can configure mode here without configuring keys right and vice-versa, all existing under "authentication" container.
Why is Autype is associated with "simple-password"? MD5 also should have an Autype of 2. As per RFC 2328: AuType Description ___________________________________________ 0 Null authentication 1 Simple password 2 Cryptographic authentication
Here simple-password is independent of Autype. Are you suggesting it should be placed outside the config container?