RE: FW: IPSec Monitoring MIB works for IPv4 only?

[Tero Kivinen <[e-mail]>]

Tim Jenkins writes:
> > In any case if we end up having (or just want to support them)
> > multiple ISAKMP SAs how are we going to represent them in the MIB?
> You describe a problem that is not the MIB's problem: how to deal with
> multiple phase 1 SAs. It's only the MIB's problem if we must support
> multiple phase 1 SAs.

Ok, I say now that I want to support multiple phase 1 SAs. 

> Can anyone tell me why we need to support multiple phase 1 SAs?
> Obviously, there will be transient times when there are multiple
> SAs during re-keying of a phase 1 SA. However, I don't see a need
> for this condition to persist.

Per user authentication.

Lets say I have unix machine having 20 users inside. Each of them have
separate certificate and private key. They want to use ipsec to
connect intranet server using that certificate. The user starts
intranet client (web?) and the underlaying ipsec engine notices that
user A wants to connect to intranet server. Ipsec engine finds out
users certificate and private key and uses them to create yet another
separate phase I SA to the intranet server. This channel is only
used to create IPsec SAs for that user, it cannot be used to create
IPsec SAs for anybody else, so when the next person wants to create
IPsec SA to same server he must do his own phase I SA to intranet
server and use that to create IPsec SA.

Here we end up having 20 phase I SAs between the unix machine and
intranet server. Each of them has different phase I ID and
certificate, but same IP address and port.

I think this is will be important case when we move from the VPN case
to the host IPsec, where all connections are authenticated using IPsec
and we want to support multiple users in the same machine.

Note that one user may have multiple phase I SAs to different
machines, so one Phase I ID may have multiple Phase I SAs active at
one time. 

> My impression of the needs for negotiating a second phase 1 SA:
> 1) A new phase 2 SA needs to be established under the protection of
> a phase 1 SA that requires more protection than an existing phase 1
> SA with the same peer.
> 2) Pending expiration of the existing phase 1 SA.
> In both cases, the old SA can be deleted once the new one is up.

I don't think both of them are very important, but per user
authentication is important. 

> > Also for mobile user case it would be nice not to tie ISAKMP SA to
> > ip-addresses but to tie them to cookies. Now the MIB uses the
> > ip-address and port numbers to identify the ISAKMP SA.
> Yes, because it's supposed to be a virtual tunnel ID, not an SA ID.
> In reality, the tunnel ID is the authenticated phase 1 ID. Should
> the index for this table be changed to the phase 1 ID?

Yes, I think so that the ipsecIkeTunnelTable should be indexed by the
Phase I ID, and the ipsecIkeSaTable is indexed by either cookies or
ip-addresses. 

> I recall that dealing with mobile IP was to be done later. Since
> the mandate of *this* MIB was to get something out quickly that
> was usable, I intentionally avoided these complications.

Is per user authentication also done later? I think it should be
already in now. There are IPsec implementations for multiuser machines
out there, and they will need that quite soon. 

> Yes, the cookies identify the SA, but not the phase 1 virtual tunnel.
> If we insist on support for multiple phase 1 SAs, I would break out
> the SA specific stuff from the IKE table like I did with the phase 2
> SA specific stuff. In that case, you'd end up with four tables, not
> three.

I think we should do it. In my last mail message I remembered that
there was something I needed multiple phase I SAs between two hosts,
but didn't quite catch what it was. Now I remember what it is and I
think per user authentication is too important to be ignored in the
mib. I don't think it will slow down the standardation, because as you
said we can just copy structure from the phase II tables. 

> > ipsecIkeSaDifHelFieldSize? How is this defined? What is the field size
> > for MODP groups? Is this really needed? (I think the field size
> > attribute in the ike is completely unused, because the field size can
> > be seen from the polynomial anyways).
> It was just an exercise in completeness. It comes from the Field Size class
> described in Appendix A of [IKE]. I'm happy to remove it if no one objects,
> if its use is either non-existent or unimportant.

I just noticed it there, and I think it is unimportant, and can be
left out from the mib, unless someone says we really need it. I think
we could also leave it out from the ike-draft also, and nobody will
notice anything.

> Good points. It was intended to indicate that SAs created within this
> phase 1 SA use PFS (as set by policy). A more appropriate place would
> be with the SA itself then, if it's wanted at all. Comments?

I would add

     ipsecTunnelDifHelGroupDesc        Integer32,

to ipsecTunnelEntry, and copy the description from the
ipsecIkeSaDifHelGroupDesc, except define that if this is 0 then no PFS
is used. I didn't realize there wasn't anything about that in the
ipsecTunnelEntry table. 

> > Why is the ipsecIkeSaTrafficLimit limited to Gauge32? Note that the
> > current IKE draft doesn't limit the size of the life duration
> > attribute (it may be variable length, although I assume all of the
> > implementations will fail, if someone tries to send 64-bit number to
> > them...).
> It's actually an Integer (misprint in -02). Anyway, at 32 bits,
> I figured 4,294,967,295 1024 byte blocks would be a reasonable upper
> limit for expressing this.

Might be, but who knows about the future. Changing it now is easy,
changing it later is hard. The mib already have lots of 64-bit
integers inside so everybody just have to support them anyways, so I
would put it as a 64-bit number instead of 32-bit, just to be sure. 

> > Why are the *Packets counters Counter32, instead of Counter64? We may
> > end up using more than 2^32 packets also... It takes for 100 MB
> > ethernet with small packets only less than an half a day to do it.
> That's fine. And what will it be over the Internet? Even over a T3
> with normal traffic, it's still likely more than a day.

I really hate to see counters that wraps too fast. People are going to
use IPsec, in other cases than VPN also, and for example the Finnish
university network backbone is 155 MBit/s ATM that covers the whole
Finland, and if they start using ipsec the counters will wrap every 4
hours... Not very usefull information. 

> I really don't want to proliferate 64-bit values unless
> they're really needed. There are still many users of SNMPv1 that
> can't support 64-bit values, so I don't want to make the translation
> any more different than necessary.

The byte counters are already 64-bit, and they are much more
important, so I assume that if the user is still using product that
supports only SNMPv1, and the cannot get that information the propably
upgrade to newer version or start using another product. We cannot
stay in one place forever. 

> > ipsecIkeSaDecryptErrors: How you defined such? Normally that might be
> > guessed from the INVALID-PAYLOAD-TYPE, DOI-NOT-SUPPORTED,
> > PAYLOAD-MALFORMED, BAD-PROPOSAL-SYNTAX error codes or something else.
> > I think it might be quite hard to categorize errors to be decryption
> > errors. At least there should be list of errors that are considered
> > decryption errors.
> > 
> > ipsecIkeSaHashErrors: I assume this doesn't contain the
> > AUTHENTICATION-FAILED error codes that are generated when phase I
> > authentication hash failes, only to the INVALID-HASH-INFORMATION that
> > are generated if the hash lenght is invalid etc. The
> > draft-ietf-ipsec-isakmp-10.txt says you should send
> > AUTHENTICATION-FAILED error code if the hash comparision fails.
> > 
> > I assume this should really be ipsecIkeSaAuthErrors if you want to
> > calculate authentication errors.
> These are SA processing errors, just like in IPSec. In other words,
> the decryption of the payload of an encrypted ISAKMP packet lead
> to a bad length or whatever.

Yes, but how do you know if the decryption failed? There isn't any
kind of checksum or similar in isakmp, that would tell if the
decryption failed. There are some errors that usually either means
decryption error or that the other end is broken, or we had bit error
in the wire. If you leave it that way you can be sure that everybody
is calculating them differently.

> The hash calculation for the authentication
> of the *packet* failed.

So only phase II HASH calculation mismatch are calculated here? Then I
think it needs more text to clarify that you mean those not Phase I
authentication failures. 

> These count packet errors in the control stream (the IKE virtual tunnel)
> as performed by the phase 1 SA. They are not protocol or negotiation
> errors.

They are. When the IKE-process gets a packet from the network it
decrypts it and then starts processing it. After that it might get
some kind of error that is sends to other end, and if that error might
be caused by decryption error (like INVALID-PAYLOAD-TYPE,
DOI-NOT-SUPPORTED, PAYLOAD-MALFORMED, BAD-PROPOSAL-SYNTAX etc) then it
also must increment that counter. So it musts know which kind of
errors in the packet are considered as decryption errors and which are
just errors in the protocol. If the other end send you Phase II packet
with payload number 14, it is INVALID-PAYLOAD-TYPE error, and it might
be caused by decryption error, or it might be that the other end is
just using newer version and incorrectly sends you new payloads. 

For somebody who has to provide this information it is quite important
to know which situations are considered to be decryption errors. 

> > ipsecTunnelLocalAddressOrStart, ipsecTunnelLocalAddressMaskOrEnd:
> > where is the type of these fields given? How does the reader know if
> > they should treat this range, subnet, or just one ip address?
> 
> If the maskOrEnd is a mask, it's a mask and the AddressOrStart is the
> subnet. A 32-bit mask means the AddressOrStart is an address. Otherwise,
> it's a range.

So maskOrEnd is defines the type of the address, and type is subnet if
the ip address in the maskOrEnd is something that has only 1-bits in
the msb end and only 0-bits in the lsb end. Huh.

Luckily I propably only need to generate those, I don't have to parse
them... It least it would need some more wording to explain that, it
wasn't obvious at least for me... 

> The values for DES40 come from a Cisco document, and were used at
> the last interoperability workshop by both Microsoft and TimeStep.

Yes. I guessed that someone other is to blame... :-)

> > Also because the MIB doesn't provide the vendor id information (I
> > think it should!) there is no way to know whose private number space
> > we are using if there are any numbers from the private number space.
> The DES40 values are not private number space; they are in co-operating
> implementations number space.

They are. The IKE draft says:
----------------------------------------------------------------------
...
   Class Values
   - Encryption Algorithm
      DES-CBC                             1
...
      CAST-CBC                            6

     values 7-65000 are reserved to IANA. Values 65001-65535 are for
     private use among mutually consenting parties.
...
----------------------------------------------------------------------
And the DOI draft says:
----------------------------------------------------------------------
...
6.5 IPSEC ESP Transform Identifiers
...
   The values 249-255 are reserved for private use amongst cooperating
   systems.
----------------------------------------------------------------------

At least I interpret those to be private number spaces, everybody can
take number from there and start using that, and if someone wants to
interoperate with them using that number, they can agree on doing
that. Nobody can reserve any of those numbers. 

> ..<snip further comments about DES40>
> > It seems to be odd that group 5 is missing, even when it is much more
> > widely supported than DES40 :-)
> At release time of -02 of the MIB, there was a document for DES40. I

I haven't seen any drafts about it in the internet-draft directory,
and quick search found DES40 or DES-40 from the
draft-hoffman-des40-02.txt and some tls documents. The
draft-hoffman-des40-02.txt doesn't mention that 65001 number. The
number 65001 hasn't been mentioned in the ipsec-list. 

> had not seen the Group 5 document at that time. Maybe I should put in
> groups 6, 7, 8, 9, 10 etc. now? :-)

Daniel Harkins's mail to [e-mail] list at Fri, 11 Sep 1998
10:48:12 -0700, with message id
<[e-mail]>, subject is "issues
with IKE that need resolution". That has at least been talked in the
working group list.

Ok, but enough for that. This isn't any kind of real issue here. 
-- 
Start fixing W2K problem,                    install free unix now.
[e-mail]                               Work : [phone]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/