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

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

Tim Jenkins writes:
> 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?

I think we can identify the phase 1 tunnels by the the phase 1
identities they are using. The phase 1 SAs can be identified by the
cookies. Note that, there might be several phase 1 SAs for one phase 1
tunnel, and the ipaddresses are only valid for phase 1 SAs, not
tunnels. I give an example:


IKE Tunnel 1 <usr@fqdn(0:0,foo@ssh.fi) - fqdn(0:0,www.intranet.ssh.fi)>
	index = 1
	IDi = type: rfc822, proto: any, port: any, data: foo@ssh.fi, 
	IDr = type: fqdn, proto: any, port: any, data: www.intranet.ssh.fi

IKE Tunnel 2 <usr@fqdn(0:0,foo@ssh.fi) - fqdn(0:0,mail.intranet.ssh.fi)>
	index = 2
	IDi = type: rfc822, proto: any, port: any, data: foo@ssh.fi, 
	IDr = type: fqdn, proto: any, port: any, data: mail.intranet.ssh.fi

IKE SA 1 <0x4e6c9c0f e2000000 - 0x5484b4fd 71000000>
	index = 1
	src IP = 192.168.2.4
	dst IP = 192.168.2.43
	IKE tunnel index = 1

IKE SA 2 <0xcaf52e31 1d000001 - 0xf2cbe754 90000001>
	index = 2
	src IP = 192.168.2.4
	dst IP = 192.168.2.44
	IKE tunnel index = 1

IKE SA 3 <0x8c80fb79 b0000001 - 0x402511bb a1000004>
	index = 3
	src IP = 192.168.2.4
	dst IP = 192.168.2.43
	IKE tunnel index = 2

Etc. So we have two intranet web servers each offering service for
www.intranet.ssh.fi name (load balancing) which have two ip-addresses
(192.168.2.43 and 192.168.2.44). We also have one mail server that is
running in the same machine than the first web server. 

The user foo@ssh.fi, have two IKE tunnels, one to the web server and
one to the mail server. The web server IKE tunnel have to IKE SAs, one
to both machines. The mail server IKE tunnel have only one IKE SA. 


> Further, how do the
> phase 2 tunnels become associated with the phase 1 tunnels?

It depends about the policy and the implementation. Either you do that
with per connection SAs, i.e. you create one IPsec SA per tcp/ip
connection. Here is a example of that (given the previous IKE
example). 

IPsec tunnel 1 <ipv4(tcp:3434,192.168.2.4) - ipv4(tcp:80,192.168.2.43)>
	index = 1
	Quick mode IDci = type:ipv4, proto:tcp, port:3434, data:192.168.2.4
	Quick mode IDcr = type:ipv4, proto:tcp, port:www, data:192.168.2.43
	IKE SA index = 1
	Encryption algorithm = ...

IPsec tunnel 2 <ipv4(tcp:3435,192.168.2.4) - ipv4(tcp:80,192.168.2.44)>
	index = 2
	Quick mode IDci = type:ipv4, proto:tcp, port:3435, data:192.168.2.4
	Quick mode IDcr = type:ipv4, proto:tcp, port:www, data:192.168.2.43
	IKE SA index = 2
	Encryption algorithm = ...

IPsec tunnel 3 <ipv4(tcp:3436,192.168.2.4) - ipv4(tcp:25,192.168.2.43)>
	index = 3
	Quick mode IDci = type:ipv4, proto:tcp, port:3436, data:192.168.2.4
	Quick mode IDcr = type:ipv4, proto:tcp, port:smtp, data:192.168.2.43
	IKE SA index = 3
	Encryption algorithm = ...


IPsec SA 123 <123>
	index = 123
	IPsec tunnel index = 1
	SPI = ...

IPsec SA 222 <222>
	index = 222
	IPsec tunnel index = 2
	SPI = ...

IPsec SA 312 <312>
	index = 312
	IPsec tunnel index = 3
	SPI = ...


Now we have three IPsec tunnels, one to the first web server and
another to second web server. Then we also have one IPsec tunnel to
the mail server. Each of those IPsec tunnels currently only have one
IPsec SA.

Another alternative would be to modify the implementation so that the
IPsec engine knows about the users, and then he can just create
similar entries than above, except the Quick mode IDci, has port any
instead of specific port number. The engine will then see that now
user foo is trying to send packets to port 25 of the 192.168.2.43 so
it should use the IPsec SA 321, because that is associated with the
IPsec tunnel 3 that is associated with the IKE SA 3, that is
associated with the user name foo...

> 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?

Not with same selectors. If the IPsec engine doesn't allow using the
username (or uid or similar) as a selector then it must use per
connection (per port) SAs. So either end up having one IPsec SA for
each of them, having selectors <src IP, dst IP, user name> or with
as many IPsec SAs as they have open connections, having selectors <src
IP, src port, dst IP, dst port>. 

> If so, how would you use them at the packet transfer level?

Again, this is implementation issue. 

> Is this the kind of thing you are trying to support? Or am I
> over-complicating this?

The MIB really doesn't have to know how the IPsec engine creates those
SAs and how it does the per user based authentication. It just have to
be able to express the resultant structure. And yes, I think we are
trying to support per user authentication over IPsec. 

> 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).

I tought that the ipsecTunnelIkeSa was for that purpose?

> 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?

For the protocol implementators point of the view the problem is quite
simple. If the policy code asks for IPsec SA from x to y authenticated
by z, and we don't have Phase I tunnel between x and y authenticated
by z, we just create Phase I SA and then IPsec SA and add all these
entries to the table. We have to maintain the mapping from IPsec SA to
phase I SA that was used to create it anyways if we want to for
example support dropping that connection when the certificate used in
the authentication is revoced. 


> > 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?

Polynomial?

???

> > 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?

Ok, for me, but I think 64-bit is enough...

> > 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?

Usually what you see is you either see invalid payload type, reserved
byte not being zero, or with unequal payload length. The errors of
course depend on the order you check things (if you check length
before reserved bytes, then you get more unequal payload lengths
instead of the reserved non being zero).

Also if you process packet only one payload at time, and the packet is
corrupted in the middle of the payload and rest is garbage, you start
getting errors inside some payload before you notice that the rest of
the payloads are also garbage.

Perhaps we could add some wording that says "If there is a any error
in the packets generic payload structure (next payload field,
reserved, payload length) then this is considered being decryption
error. If any error happens inside the payload structure, then it is
not assumed being decryption errors."

This means that you should check the whole packets generic payload
structure first before you start looking inside the payloads. This
means that if we flip one bit inside the payload we do not end up
having decryption error, but something else, but if we flip it in the
any of the generic payload headers then we end up having decryption
errors. 

> > 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?

Yes. Just adding

    ipsecTunnelLocalIdType		Integer32
    ipsecTunnelRemoteIdType		Integer32

and copying their descriptions from the ipsecIkeSaPeerIdType would be
fine. 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
References: