Re: 2nd try

[Mark Duffy <mduffy@quarrytech.com>]

Thanks, Steve.  This gives a very nice summary of the issues!  And, I agree 
in general with the recommendations.  Some specific comments/questions 
embedded below...
--Mark

At 09:05 PM 3/22/2004 -0500, Stephen Kent wrote:
...
>In 2401bis, we have explicitly said that it's OK to use transport mode in 
>cases where the IPsec implementation is not the ultimate destination, 
>e.g., between two SGs. In principle, this creates a new opportunity for 
>outbound, plaintext fragments to be mapped to a transport mode SA for 
>IPsec processing. However, in these new contexts in which a transport mode 
>SA is now approved for use, it seems likely that we can continue to 
>prohibit transmission of fragments, as seen by IPsec. For example, in an 
>IP overlay network, packets being sent over transport mode SAs are 
>IP-in-IP tunneled and thus have the necessary inner header to accommodate 
>fragmentation prior to IPsec processing. When carried via a transport mode 
>SA, IPsec would not examine the inner IP header for such traffic, and thus 
>would not consider the packet to be a fragment. Thus it seems reasonable 
>to retain the prohibition on carrying IPv4 fragments on transport mode 
>SAs, even when the source or destination is an SG.

My suggestion would be to simply say (e.g. in 2401bis sect 4.1):

The use of transport mode by intermediate devices (e.g. SGs) is permitted 
only when applied to packets whose source (for outbound packets) or 
destination (for inbound packets) address is an address belonging to the 
intermediate system itself.  In these cases the intermediate system is 
essentially acting as a host with respect to those packets.


...
>If we simplify the procedure employed to locate the next layer protocol in 
>2401bis, so that we treat ESP and AH as next layer protocols, then the 
>notion of an encrypted next layer protocol field has vanished, and there 
>is also no need to worry about encrypted port fields either.

Yes please.  In fact, I thought this was already decided.  I.e. in 
2401bis-01 section 4.4.2 Selectors:  'Next Layer Protocol: Obtained from 
the IPv4 "Protocol" or ...'


...
>Conclusions
...

>1. All implementations MUST support tunnel mode SAs that pass traffic 
>without regard to port field values.

And must support bypass/drop rules that operate without regard to port 
field values, no?

...
>2. All implementations MUST support tunnel mode SAs that will carry only 
>non-initial fragments, separate from non-fragmented packets and initial 
>fragments.

And must support bypass/drop rules that will match only non-initial 
fragments, no?

...
>Also, because a SA of this sort will carry ALL non-initial fragments that 
>match a specified source/destination address pair and protocol value, 
>users and administrators are advised to protect such traffic using ESP 
>(with integrity) and the "strongest" integrity and encryption algorithms 
>available at both peers. (Determination of the "strongest" algorithms 
>requires imposing a total ordering of the available algorithms, a local 
>determination at the discretion of the initiator of the SA.)

Isn't it also at the discretion of the responder?


>3. An implementation MAY choose to support some form of stateful fragment 
>checking for a tunnel mode SA with non-trivial port field values (not ANY 
>or OPAQUE). Implementations that will transmit non-initial fragments on a 
>tunnel mode SA that makes use of non-trivial port selectors MUST notify a 
>peer via an IKE payload (TBD). The peer MUST reject this proposal if it 
>will not accept non-initial fragments in this context. If an 
>implementation does not successfully negotiate transmission of non-initial 
>fragments for such an SA, it MUST NOT send such fragments over the SA. 
>This standard does not specify how peers will deal with such fragments, 
>e.g., via reassembly or other means, at either sender or receiver. 
>However, a receiver MUST drop non-initial fragments that arrive on an SA 
>with non-trivial port selector values unless this feature has been negotiated.

This wording does not preclude an implementation from negotiating this 
feature but then failing to do the expected checking on received 
packets.  Should it state that if the feature has been negotiated, the 
receiver MUST NOT accept non-initial fragments without verifying that they 
comply with the security policy called for for the overall packet?

Also, I think that #3 also should state that a receiver that has negotiated 
the feature must not accept non-initial fragments for bypass without 
verifying that they comply with the security policy called for for the 
overall packet.

------------

One final issue, does port selector ANY encompass OPAQUE?  To my 
sensibilities ANY means any value in the range (e.g. 0..65535) and the port 
values of an opaque packet are surely in this range even if we don't know 
them.

If there is some value (what is it?) in having an ANY concept that does not 
include OPAQUE, it should be clearly named e.g. ANY_NONOPAQUE.

Here is at least one specific reason why ANY *should* include 
OPAQUE.  (Yes, I realize that this is an arcane case.)  For approach #1 we 
use port-blind policies.  If ANY includes opaque then the port selectors 
are simply:

     source port = ANY, dest port = ANY.

But if ANY and OPAQUE are disjoint then (here's where it gets arcane 
;-)  it is possible that a an initial fragment will come along that 
contains the source port but not the dest port.  The policy for approach #1 
to cover this case would need to be:

     source port = ANY, dest port = ANY
or  source port = ANY, dest port = OPAQUE
or  source port = OPAQUE, dest port = OPAQUE

What administrator is going to think to provision that?


--Thanks, Mark