[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: IPSec Monitoring MIB works for IPv4 only?
The point that Tero raises seems to come close to reprising a
question that was discussed on numerous earlier occasions in
the working group. I feel that it is still a good question.
User keying at layer 3 (or 3-4 if you like) creates an expectation
for being problematic, because in the general case one expects any
layer N entity that provides services at layer N+m where m is greater
than 1, to be problematic.
The last time I ventured to offer any comment about this (2-3 years
ago), we had a very long (and heated) discussion. Some members of
the group cited examples from NFS and other multiplexing protocols.
These examples still seem to be good food for thought.
Regards,
Mitch Nelson
On 19-Nov-98 Tero Kivinen wrote:
>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 ipsec@tis.com list at Fri, 11 Sep 1998
>10:48:12 -0700, with message id
><199809111748.KAA09458@dharkins-ss20.cisco.com>, 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.
>kivinen@iki.fi Work : +358-9-4354 3218
>SSH Communications Security http://www.ssh.fi/
>SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
References: