[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mib

Hi,

I am also a recent reader of this MIB, and have various questions. Forgive me
if this has already been discussed, I am also a recent subscriber to this
mailing list...

1.
SA definition.
I kow everywhere it is said that one of the three keys to identify an SA is an
IP destination address: It makes little sense to me. The meaning of
"destination" is different depending on wether we deal with an inbound or
outbound SA.

For an outbound SA, the destination address is actually the right key.

For an inbound SA, the IP address wich allows us to uniquely identify an SA,
along with the SPI and the protocol, is the SOURCE IP address. There is no
reason why two remote peers would not allocate the same SPI.

RFCs make this confusing.


2.
Shouldn't the selectors table be divided into inbound and outbound selectors? I
can see you chose "local" and "remote" rather than "source" and "destination"
to make a SelectorEntry generic. But what is the idea here? Do you implicitely
consider that the inbound and outbound selectors of a given SA are symmetric,
that is you just swap destination and source for IP addresses and Port numbers?



3.
My understanding is that Inbound and Outbound SAs provided by a single Phase 2
negotiation only differ by their Key (because they have different SPIs).
Everything else is identical: same IPSEC protocol, same transform, same
lifetime, and the selectors are symmetric.

Is this correct?

If yes does it still make sense to have inbound and outbound SA tables?

Also if yes, I never understood how the lifetime in kiloBytes is working: I
mean is it applied to each SA or to both SAs together (inbound + outbound
traffic).


Sorry for asking so many questions at once...

Any light you can shed on any of these issues woud be greatly appreciated.


Thanks & Regards,

Emmanuel Hislen.



Tim Jenkins wrote:

> > -----Original Message-----
> > From: kris FALKOWSKI [mailto:kfalkowski@yahoo.com]
> > Sent: Thursday, April 19, 2001 1:54 PM
> > To: TJenkins@Catena.com
> > Cc: ipsec@lists.tislabs.com
> > Subject: mib
> >
> >
> > Tim;
> > I don't have many experiences with IPSEC MIB so let me
> > ask a few questions.
> > First: In IPSEC monitoring MIB there are many times
> > reference  like this: ""The value is taken directly
> > from the optional ID payloads that are exchanged
> > during phase 2 negotiations"". In any references like
> > RFC and Doraswamy/Harkins book - ID payloads are not
> > optional. Could you comment?
>
> RFC 2409 states that the IDs used in quick mode are optional. That is the
> basis for those statements. (Look on page 18 near the middle of the page.)
>
> > Second.
> > The tables for IKE monitoring MIB drafts are very
> > entangled and complicated. Could you offer me some
> > guidance why there are so many methods and options to
> > search for SA and how practically I can understand all
> > this.
>
> The reason why there are so many ways to look up SAs is that there are many
> ways that people might be interested in seeing how SAs are being created or
> used. That's why so many helper tables were included. Since the RFCs on
> which the MIBs are based is application independent, the MIBs are also
> application independent, but at the same time make an attempt to assist
> application specific uses of IPsec.
>
> The text to explain the inter-relationships between the MIB tables has
> undergone numerous changes since the initial version. At this point, unless
> there's something specific which isn't clear, I don't how I can help clarify
> those relationships. Note that part of the reason for the relationships is
> due to the relationships of IKE to ISAKMP to IPsec SAs.
>
> Perhaps if for each of the helper tables you try think of a use for them, it
> might help you to understand why they are there. For example, selectorTable
> lets you sort the SAs based on selectors. This would be useful to see what
> SAs a particular type of traffic would put be put through or is being put
> through. The use for this is in a VPN application or for remote access, for
> example.
>
> > Thank You,
> > Sincerely
> > Kris Falkowski
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Auctions - buy the things you want at great prices
> > http://auctions.yahoo.com/
> >

--
Emmanuel Hislen
Lucent Technologies
mailto:hislen@lucent.com
References: