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

Re: some issues about IPSec

Xuechen,

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

Manual keying is not a problem, but the new I-Ds do require you to support
both tunnel and transport modes, unless your BITS implementation is
destined for use only on security gateways.  At one time I proposed
restricting BITS implementatiions to tunnel mode only, but at least one
vendor was implementing transport mode and argued against that, so ...
Also, there is a need to support administrative configuration that may be
more sophisticated than the preceeding paragraph would suggest.

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

Yes, this type of checking is consistent with the current specs, for a BITS
implementation.

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

That would not be consistent with the current specs, which require a check
against source and destination IP addresses, next protocol, and, if
applicable, port fields.

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

There is no requirement that a user specify both source and destination
port for every SA, i.e., ANY is an OK choice for either or both of these
fields in the SPD.  However, there is a requirement that your
implementation allow a user to enumerate specific ports for both source and
destination, if the user desires.  Also note that an SPD entry might
specify ANY for a source port and specify a given destinaion (well known)
port, but call for a different SA each time a different source port is
used.  That behavior matches your characterization of updating the SPD
whenever a new source port is selected by a user.  Prior ot your message, I
dont recall a suggestion that we define a different set of requirements for
BITS implementations vs. native host implementations.  Also, the roles of
client and server may both apply to a given host, so a distinction  made on
this basis may not be a good idea.

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

As you may recall, ESP and AH in transport mode are applied only to whole
datagrams, not to fragments.  This has been true for a long time, but
you're right that it makes like more difficult for BITS and BITW
implementations. This was part of my reason for suggesting tunnel-only mode
for BITS, as noted above, but that's not what the WG decided to pursue.
So, for now, you are required to assemble the fragments and apply ESP prior
to transmission, in transport mode.  To do otherwise would introduce a
requirement to process ESP fragments for other host iplementations.  So,
the processing you describe above is precisely what must be supported in a
BITS implementation.

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

I'm not sure what point you're trying to make here.  The bottom line is
that ESP is applied only to whole datagrams in transport mode. To do
otherwise may pose problems for receiving hosts, e.g., in the face of
missing port fields in later fragments.

Steve
Follow-Ups: References: