[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: IPSec Monitoring MIB works for IPv4 only?
---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: Thursday, November 19, 1998 3:49 PM
> To: Tim Jenkins
> Cc: ipsec@tis.com
> Subject: RE: FW: IPSec Monitoring MIB works for IPv4 only?
>
>
<snip>
> > > 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.
>
Okay, I've been convinced to add the separate table for phase 1 SAs.
Now, given the discussion that's occurred about how to identify a
phase 1 tunnel (IKE channel?), how do the SAs in the phase 1 SA table
become associated with the phase 1 tunnels? Further, how do the
phase 2 tunnels become associated with the phase 1 tunnels?
Take your multi-user example: Say you've got two users, both
authenticated. They both want to access a server, so they end
up needing a phase 2 tunnel with the same selectors. Are there
now two phase 2 tunnels with the same selectors created? If so,
how would you use them at the packet transfer level?
Is this the kind of thing you are trying to support? Or am I
over-complicating this?
The intent was to link phase 2 tunnels to the phase 1 tunnel
based on the tunnel endpoints (for tunnel encapsulation) or
the IP header IP addresses (for transport encapsulation).
Now, you're suggesting we need multiple phase 1 tunnels with
the same endpoints, that are distinct. So how do we link the
phase tunnels to them? Do we force implementations to do it
based on creator?
<snip>
>
> > > 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.
And polynomial, etc. etc. right?
>
> > > 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.
>
But, if its going change, shouldn't it then be changed to be unlimited
length?
In any case, I'll go to 64-bit for more of the counters.
<Lots of snipping going on...>
> > > 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.
Fine. Anyone care to take a stab at what should be where?
>
> > 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.
>
Okay, I'll clarify that.
<snip>
> > > 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...
Would you prefer another field that states how to interpret those
fields?
<snip>
Follow-Ups: