Re: Last Call: RIP-II Cryptographic Authentication to Proposed

[William Allen Simpson <[e-mail]>]

> The IESG has received a request from the RIP  Working Group to consider
> "RIP-II Cryptographic Authentication" <draft-ietf-ripv2-md5-01.txt> for
> the status of Proposed Standard.
>
Having gotten a set of Photuris drafts out the door, I now have a small
amount of time to review others while folks are reviewing mine.

I don't understand the need.  Why not use AH???

One of the rationales is that SNMP has authentication, but I hear they
are removing it?!?  In that case, we shouldn't have a separate one in
RIP, OSPF, et alia.

And, the KeyID is too short to be used with Photuris.  (This won't work
with SKIP at all, of course).

The association of a keyID and an interface seems wrong to me.  That's
almost Source associated keying, instead of Destination.

Should be restated as keyID and broadcast/multicast destination, which
is associated with a _link_ accessed by a particular interface!  (Same
effect, better conceptualization).

And a few grammer and typos on first glance:

    connectivity to the neighbor has been lost.  Acceptable messages are now
    truncated to RIP-II message itself and treated normally.
                ^^^ the

    Hence it is possible to have fairly smooth RIP-II Authentication Key
        ^^^ comma

The order of sections is unusual.  Should be Security Considerations,
References, Acknowledgments, chair, authors.  That way, the internal
self-references are in the right order (and that's the order in the
"official" guideline, or it used to be :-)

Actually well-written overall, particularly on key lifetimes.  I should
steal some text for Photuris....

Obviously, we need an ICMP message for notification:

    In the event that the last key associated with an interface expires, it
    is unacceptable to revert to an unauthenticated condition, and not
    advisable to disrupt routing.  Therefore, the router should send a "last
    authentication key expiration" notification to the network manager and
    treat the key as having an infinite lifetime until the lifetime is
    extended, the key is deleted by network management, or a new key is
    configured.

I expect we'll handle that in IPSec.  Needed for Photuris, too.  (OK,
OK, over the weekend....)  You shouldn't publish this without
referencing the actual ICMP message, as it is dependent for correct
operation.

I haven't gotten a rip2 mailing list message since '92, and didn't know
you were working on this.  Hopefully, the authors can forward discussion
to the list where they discussed this.

My conclusion is I oppose this going forward, instead of using IPSec.
Sorry (the authors being freinds of mine).

[e-mail]
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2