Re: 2nd try

[Stephen Kent <kent@bbn.com>]

At 7:10 PM -0500 3/25/04, Mark Duffy wrote:
>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.

I think some words along these lines can be used.

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

just wanted to reiterate and make sure we all agree.

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

  we should group the bypass/drop requirements together. just as they 
were discussed separately in the memo. sorry that I didn't make this 
explicit.

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

ibid.

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

in the sense that a responder must agree to SA parameters proposed by 
the initiator. The initiator must propose only what he considers to 
acceptable algorithms given the context.

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

good point. we'll add that note.

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

we can say that too. but it is implied by the required, normal SA 
receiver processing rules.

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


The memo says that ANY and OPAQUE are disjoint and it explicitly said 
that you would need to define an SA that used BOTH ANY and OPAQUE 
port selectors if you wanted a single SA for all traffic of this sort.

Nonetheless, I think you are right, i.e., we can redefine ANY to 
encompass OPAQUE and still be OK. OPAQUE must be kept separate to 
allow us to have a fragment only SA when we have port-specific SAs, 
but defining ANY the way you suggest makes it easier to define an SA 
that carries all traffic (non-fragmented, as well as initial and 
non-initial fragments) that otherwise matches the other selectors, 
when we want to not be port-specific. This makes it easier for admins 
too, as you note. Is also is more consistent with the convention I 
proposed for protocols that have no ports (or only on port), since I 
had suggested using ANY as the port field selector value for such 
protocols.

Steve