[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New IPSec Monitoring MIB draft
(I won't comment the generic structure of this proposal, just some
details.)
John Shriver writes:
> ikePhase1SaDifHelGroupDesc INTEGER
> ikePhase1SaDifHelGroupType INTEGER
...
> ikePhase1SaDifHelGroupPrime OCTET STRING
> ikePhase1SaDifHelGroupGenOne Integer32 (or must it be OCTET STRING?)
> ikePhase1SaDifHelGroupGenTwo Integer32 (")
> ikePhase1SaDifHelGroupCurveA Integer32 (")
> ikePhase1SaDifHelGroupCurveB Integer32 (")
Those must be octet string, because they are quite often real bignums.
> ikePhase1SaDifHelGroupOrder OCTET STRING
>
> Then, we have to decide if the MIB is obligated to fill in these
> values for standard Groups, or whether it is filled on only when the
> GroupType is 0. Or perhaps it's clearer if we define GroupType to be
> -1 if non-standard, or have a TruthValue SYNTAX variable incidating
> non-standard group.
Group type is MODP(1), ECP(2), or EC2N(3) for the non-standard groups.
Because you cannot give Group Descriptor if you defined group in Phase
1, I assume easiest way would be to define it so that you give either
only the group descriptor (for standard well known groups), or all
necessary parameters (type, prime, gen1, gen2, curve a, curve b,
order) except group descriptor for the private groups.
> As for the SA lifetime variables, I think Counter64 is safe. Really,
> who is going to use "bignum" math in their SA's to count the lifetime
> in kbytes? Nobody will accept (or properly implement) a lifetime with
> a length greater than 8 bytes. For that matter, I think lifetimes in
> seconds can be limited to 4 bytes, that's 136 years. (68 years if you
> want to allow for sign bugs.) These are really flaws in the DOI, it
> doesn't prohibit insane values...
Why do we want to use kilobytes? I think Counter64 in bytes is almost
enough. It is constant 5 GBytes/second for 100 years, or 50
GBytes/second for 10 years, or 0.5 TByte/second for 1 year. I don't
think anyone wants to use LIFETIME of that big...
Yes, I agree that 4 bytes for lifetime in seconds is enough.
> Next, I'd rather have a seperate variable for lifetime in kbytes versus
> lifetime in seconds. Why? Becuase you can then put proper UNITS
> statements on each. So, we would have:
> ikePhase1SaLifeType INTEGER { none(0), seconds(1), kilobytes(2) }
> ikePhase1SaTimeStart DataAndTime
> ikePhase1SaTimeLimit Counter32 UNITS "Seconds"
> ikePhase1SaByteLimit Counter64 UNITS "Kilobytes"
Note, that in IKE you might have both second and kilobytes limit at
the same time, so you need both(3) value above, or just leave it away
and say that if TimeLimit or ByteLimit is zero then there is no limit
for that unit.
> Now we come to another major issue. There is no limit of one
> Certificate Payload per SA. You ROUTINELY will have a chain of
> certificates. But that's not possible with this MIB. So, we need a
> table for certs.
Yes, you can have multiple certificates, but at the end you only have
ONE end user public key you use in the authentication take from the
certificate. There isn't a reason to include the whole path, only the
end user certificate used in the authentication is really interesting.
> It would be really nice if there was some way to have the Protection
> Suite entry point back to the Phase 1 SA. We could have the two
> cookies, with a syntax similar to IfIndexOrZero, where Zero means that
> the Phase I SA is no longer there. (If I can't win the cookie index,
> then it can be the arbitrary index, where 0 is a reserved index.)
This, I think, is quite important, because this really ties the IPSec
SA to the authentication. This is needed if we ever want to do any
kind of user based accounting etc for the IPSec traffic.
> There's rather a mish-mosh between Inbound/Outbound and Local/Remote
> in the proposed table. That will get realy confusing if we create the
> proper 4 variables:
> ikeProtSuiteLocalLocalPort
> ikeProtSuiteLocalRemotePort
> ikeProtSuiteRemoteLocalPort
> ikeProtSuiteRemoteRemotePort
What are these four variables? If they are quick mode identity port
numbers, there are only two identities, not four. The responder must
give back same identities what the initiator sent.
> Again, as in the ISAKMP SA, we need the FULL set of Diffie-Hellman
> group parameters.
In that case should we add separate table describing the groups
defined in the new group mode.
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
Follow-Ups:
References: