[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
some issues about IPSec
Hi Ken & Randall,
Sorry the late comments.
I like to have your opinions on some issues. Basically we already got a
bump-in-the-stack implementation for Windows 95 and Windows NT working.
This implementation supports multiple security channels between two hosts
or host and security gateway or two security gateways. User can configure
which application protocol to protect (FTP, TELNET, HTTP...) and what kind
of algorithm to use. Now it only works with manual key management and only
in tunnel mode.
But it doesn't fully support the latest draft you wrote (Nov. 1997). It
doesn't support ICMP PMTU message parsing, though it does parse ICMP
redirect message. (Driver maintains its own routing table. Every tunnel
point/security gateway has its own entry in this table. If no entry existed
for a security gateway, after driver applied certain SAs to the outgoing IP
packet, driver always sends the packet to the same network interface that
the original IP packet was targeted to. If driver received an ICMP redirect
message from the router, it will update the routing table according the
information contained in that ICMP message. Anyway, this is just a local
implementation matter, it's not my question. :) ).
(1) Although we didn't intend to implement IPSec server (e.g. NT server
gateway) driver as well, we had to do internal test between two hosts and
they both had our IPSec drivers installed. We found out we have to let user
choose host type based on per protocol: CLIENT or SERVER. For instance:
assume we have two hosts A and B. We use A as a FTP server, and configure
both of them to enable IPSec protection and use same encryption algorithm
and authentication algorithm. If we try to FTP A from B, the IPSec
implementation on B has to check the destination port number combined with
destination IP address and transport type of every outgoing packet to
decide whether this packet should be applied with the SA which was assigned
to protect FTP channel between A and B. On the A (server) side, the IPSec
implementation has to check the source port number instead of destination
port number.
But of course, we can simply the approach: if either destination or source
port is equal to 20 or 21, driver applies the SA. But I don't think it's a
good way.
I thought another way and that is implied by your draft: In SPD, user has
to define both source port number and destination number for every
connection. Whenever user opens a socket, IPSec implementation will update
SPD and use the new source port number as a selector (on client side if the
destination number already existed as a selector). However, it's difficult
to implement for BITS. And I think it's more natural if we only let user
choose the well-known port number defined for server. On server side,
that's the source port; on the client side, that's destination port.
(2) Fragmentation in transport mode for BITS
For the implementation of integrating IPSec into natural TCP/IP stack,
fragmentation won't be an issue. But for BITS implementation, fragmentation
is worth to mention in transport mode. The problem is when BITS-IPSec
implementation receives an outgoing packet from TCP/IP stack, this packet
could be a fragment. In this case, it will be fine if this packet doesn't
need to protected; but if implementation can find a SA for this packet by
matching selectors, the IPSec implementation can not send out this packet
right away, it has to wait until it receives all the fragments of the
datagram. Then (I)It has to reassemble them into a whole IP packet (II)
IPSec processing (encryption and digestion) (III) then do fragmentation.
The performance could be improved if the implementation doesn't reassemble
the fragments, actually it can still fragment each piece separately if it
can calculate the fragment offset by taking count in the security protocol
header size and extra IP headers. But because the IPSec packet could be
fragmented again and again during the route, receiver will have
difficulties on figuring out the correct order between IPSec process and
reassembly.
Sorry for bothering you. However, Microsoft won't have these problems. :-)
Appreciate your time!!
Xuechen
~~~~~~~~~~~~~~~~~~~~
Xuechen Yang
Vice President Engineering
xuechen@osgroup.com
(512)322-0676
~~~~~~~~~~~~~~~~~~~~
Ashley Laurent, Inc.
www.osgroup.com
707 West Avenue, #201
Austin TX, 78701
~~~~~~~~~~~~~~~~~~~~
Follow-Ups: