Subject: Questions (and answers) about the VRRP MIB

From: Brian Jewell <[email-masked]>
Date: Tue, 11 Jan 2000 08:29:03 -0800 (PST)

Hi Ifat,

re: questions about the "vrrpOperAuthKey" object in the VRRP MIB:

you wrote:
> What I meant was that in the ADV. packet there are 4 octets reserved for 
authentication data. (Actualy 2 four octets for two authentication data.) 
> So how come that the authentication key in the MIB can be up to 16 octets? 
Aren't authentication key and authentication data the same thing?

=============

I think the confusion arises from the fact that any AH data would be carried in 
the IP packet separate from the VRRP advertisement packet. Thus, if AH is used 
to provide security for VRRP, the mechanisms that make it work are the ones 
provided by IPSec - not anything provided by the VRRP implementation. So there 
would be no AH-related data in the advertisement packets - it would all be 
present in the IP packet carrying the advertisement packet and would be 
processed prior to reaching the VRRP router. So, in this area, the VRRP MIB 
mainly functions to allow configuration of AH security if a user chooses to do 
so.

Also, check section 5.3.10 of the latest VRRP Spec. Draft. It indicates that the 
Authentication Data field is used for "simple text authentication" only.

In reality, a user would probably use an IPSec MIB (when one becomes a standard) 
to configure AH security between to VRRP routers, and the vrrpOperAuthKey object 
provides a redundant means to set the key.

The VRRP RFC does not provide much information in the area of security. I think 
efforts are underway to enhance this section of the RFC.

-Brian

> Hello again,
> 	Concerning my former question:
> 3) The definition of  vrrpOperAuthKey ( page 19) states that the key length 
can 
> be up to 16 octets, but isn't it true that in the Adv. packet there's space 
only 
> for 4 octets(   	according to RFC 2338 section 5.1 )?
> 
> What I meant was that in the ADV. packet there are 4 octets reserved for 
authentication data. (Actualy 2 four octets for two authentication data.) 
> So how come that the authentication key in the MIB can be up to 16 octets? 
Aren't authentication key and authentication data the same thing?
> Thanks, 
> 	Ifat.
> 
> > -----Original Message-----
> > From:	Brian Jewell [SMTP:[email-masked]]
> > Sent:	> å 07 éðåàø 2000 17:37
> > To:	[email-masked]; [email-masked]
> > Cc:	[email-masked]
> > Subject:	Re: vrrp mib definitaions
> > 
> > Hi Ifat,
> > 
> > Here's the answers to your questions:
> > 
> > 1) and 2) Actually, VRID does not uniquely identify a VR. In Section
> >    3.0, RFC 2338 indicates that a VRID can be re-used, as long as
> >    it is used on a different LAN - which essentially means a
> >    different IfIndex. So, to uniquely identify rows in the  
> >    tables (or to uniquely identify a virtual router), both the VRID and 
> >    the IfIndex is required.
> >  
> > 3) vrrpOperAuthKey can be set via SNMP. It is never contained in a VRRP
> >    advertisement. I think this is your concern, but let me know if
> >    I'm wrong.
> >  
> > 4) The "vrrpOperAuthKey" always returns a NULL octet string when read
> >    for security; Don't want SNMP managers to be able to read this key.
> >    
> > Hope this answers your questions, but let me know if you need more 
information. 
> > I would appreciate maybe being able to use you as a reference as the MIB 
moves 
> > toward draft standard and there is a call for people who have implemented 
the 
> > MIB.
> > 
> > -Brian 
> > 
> > 
> > > Hello,
> > > 
> > > I'm about to implement the VRRP, and have some questions concerning the 
MIB 
> > definitaions in draft-ietf-vrrp-mib-09.txt:
> > > 
> > > 1) Why is ifIndex a part of the index of vrrpOperEntry ( Doesn't 
vrrpOperVrId 
> > define the entry uniqly ) ?
> > > 
> > > 2) Why is ifIndex a part of the index of vrrpAssoIpAddrEntry ( Don't  
> > vrrpOperVrId+vrrpAssoIpAddr define the entry uniqly ) ?
> > > 
> > > 3) The definition of vrrpOperAuthKey ( page 19) states that the key length 
can 
> > be up to 16 octets, but isn't it true that in the Adv. packet there's space 
only 
> > for 4 octets(   	according to RFC 2338 section 5.1 )?
> > > 
> > > 4) This same definition of  vrrpOperAuthKey ( page 19) states that "When 
read, 
> > vrrpOperAuthKey always returns an Octet String of length zero." - Do you 
mean by 
> > that that  	in the returned Octet String the value in the length field will 
> > not match the real length of the string in the string field? 
> > > 
> > > Thanks a lot,
> > > 	Ifat Gaabay.
> > > 
>