Folks, Obviously the point that Erblichs is trying to make is that OSPF may be "technically" capable of supporting HMAC-SHA authentication in its current form, but OAM may be an issue and it may become harder to debug an auth mismatch.
In the end the operator can always look at the router configurations in case OSPF doesnt come up and would know that the auth algos dont match. This can then be fixed. Yeah ..Yeah .. I understand this! What i miserably fail to understand is the reluctance in the WG to use a new authentication type. We have 16 bits reserved for this field and i dont see this being used up any time in the coming future. Explictly indicating the auth algo details in the header makes, in my view, debugging extremely easy. I understand that we would be eating up type codes that we would have to fill in the OSPF header each time we come up with a new authentication algorithm but given the size of this field i dont think its a point of concern. Is it possible to poll the WG on what they think is the right approach? Chairs, Authors? The poll should be on whether we should proceed as-is in the draft or should we use a new type field for each new authentication scheme that we come out with? On 20/08/06, Phil Cowburn <[EMAIL PROTECTED]> wrote:
I strongly agree with Manav here and an implementation must be able to demultiplex using the Key ID in the incoming packet. It is afterall for this very reason that we put the Key ID in the packet. Erblichs point, as i read it is, that most implementations (if not all) currently take type 2 to mean MD5. This may break once this draft becomes a standard, which it would, in some time. My take on this is that even if the WG agrees to Erblichs solution and introduces a new type, say 3 for HMAC-SHA-1 authentication, then somebody else could repeat the same argument and clamour for a new type when we're introducing newer authentication algorithms in the future. Lets move on from this issue. Phil
-- Toms. _______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
