Subject: (IPng 7211) RE: Last Call: Mobility Support in IPv6 to Proposed Standard

From: Richard Draves <[email-masked]>
Date: Fri, 19 Feb 1999 13:23:26 -0800

> The IPsec architecture does not envision processing by 
> intermediate nodes
> in the fashion you allude to. Only end systems and security gateways
> perform IPsec processing, and they are arranged in pairs to 
> bracket SAs.

I'm not suggesting anything that would change the pairwise nature of
security associations. I'm suggesting that intermediate destination node
that is processing a  routing header be treated as a security gateway, so
the sending node can have tunnel-mode security associations with the
intermediate node and the sending node can have security associations with
the final destination node.

What alternative are you suggesting? Are you saying that an IPsec-enabled
node should drop any packet with a routing header? Or are you saying that an
IPsec-enabled node should process the routing header & forward the packet
and bypass all IPsec processing?

Thanks,
Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Quaizar Vohra <[email-masked]>
Date: Fri, 19 Feb 1999 17:29:09 -0800 (PST)

Rich,

>  
>  
> I believe that an IPsec-enabled node that is processing a routing header
> with non-zero Segments Left should do inbound IPsec processing (SPD lookup &
> policy verification) when it gets to the routing header and outbound IPsec
> processing before sending the updated packet. This should be just the same
> as a security gateway that is forwarding a packet. The routing header should
> not make it possible to bypass security policies.

I would think that if the intermediate dest (defined per the routing
hdr) gets an IP packet, it should not do inbound IPsec processing, as
it is not the final dest for the packet, i.e it is not one of the
endpoints of the IPSEC session. On the otherhand, if the packet was
tunnelled to it then it would make sense to do inbound IPSEC
processing.

Security gateways only operate on tunnelled packets, destined to it.
I agree that it is not the final destination, but is in the sense
of the IPSEC session.

Yes if the intermediate dest (one of the intermediate IP addresses in
the routing header) is a security gateway, it should do the outbound
IPSEC processing.

> 
> Carrying forward the analogy with security gateways, the IPsec processing
> associated with a routing header should only support tunnel-mode
> associations. Otherwise it makes life too difficult for the node processing
> the routing header, because it would have to be finding & removing &
> inserting headers in strange places. Security gateways must only support
> tunnel-mode associations.
> 
> To make this concrete, suppose we have four nodes A, B, C, D. Node A sends a
> packet with a routing header through nodes B and C to node D. Node A can
> have tunnel and/or transport mode associations with node D, say for example
> transport-mode AH. Node A can only have a tunnel mode association with node
> B, say for example tunnel-mode ESP.
> 
> The packets sent by node A will look like
> IPv6 hdr - dst B, src A
> ESP
> IPv6 hdr - dst B, src A
> Routing hdr, segments left = 2, addrs C, D
> AH
> Transport hdr
> 

I would assume that each associations are related with some policies,
which classify based on some fields in the packet.

If node A has an association with D for this particular flow, then I
am not sure if it needs to have another policy  for the same flow
which requires a tunnel mode security association with B and vice versa.

A default policy which requires a tunnel mode association for any
packets between A and B, should not be applicable either, as B is not
the actual destination for this packet.

> There might be further tunnel-mode associations between nodes B & C, nodes C
> & D but node A won't know about that.
> 
> Note that this means that outbound IPsec processing on node A has to happen
> *twice*, first for the final destination node D, and then again for the
> first intermediate destination node B.

I don't understand why it should happen for the intermediate dest B, unless
you have a policy which says that for all packets destined to intermediate 
destination B, use a tunnel mode association with B.

Here your processing of the packet looks like as if it was originated
twice, once as destined to D, and then destined to B. To me, it seems
better to consider the packet as originated once, destined for D.

I am not sure if routing header should be given the same semantic as
a tunnelling header, in the IPSEC context. 

Sorry, if I am way offtrack in my understanding of this debate.

Quaizar

> 
> Does this sound reasonable?
> 
> Applying this to the mobility case, there's only one intermediate
> destination address and the final destination and the intermediate
> destination address happen to both be assigned to the mobile node.
>  
> Suppose the correspondent node has an active transport-mode AH association
> for a TCP connection with the mobile node. Then the mobile node wanders off
> and acquires a care-of address behind a security gateway. The correspondent
> node needs to use tunnel-mode ESP to the security gateway to reach the
> care-of address, and then transport-mode AH for the home address.
>  
> This demonstrates the example above: when the correspondent node sends to
> the mobile node, it needs to do outbound IPsec processing twice, first for
> the home address, then for the care-of address.
>  
> Thanks,
> Rich