Subject: (IPng 7227) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard

From: Richard Draves <[email-masked]>
Date: Mon, 22 Feb 1999 20:06:41 -0800

> I am sorry I was unclear in my last mail. When I said that SG will not
> do inbound IPSEC processing, I did not mean that it will not check its
> policies to see if the packet should have come encrypted to it
> If it has such a policy, it should drop the packet.
> 
> Eric already clarified this.
> 
> The intention of my previous mail was to say that the presence
> of source routing header in a packet should not change the IPSEC
> behavior either at the inbound or outbound. While a routing
> header might be considered as part of policy lookup, if an
> implementation allowed defining IPsec policies filtering on
> intermediate destination.

I'm trying to keep things "simple" and not even consider policies that
filter on routing headers.

So are we in agreement that an IPsec-enabled node that is processing a
routing header should do inbound & outbound IPsec processing, much like a
security gateway that is forwarding a packet? Then I don't understand the
point you are trying to make.

One thought that occurs to me: to revisit the example of a node SG that
receives a packet
	IPv6 hdr - src A, dst SG
	Routing hdr - segs left = 1, B
	Transport hdr

When node SG is doing its inbound SPD lookup, what selectors should it use?
Should the destination address selector be SG or B? In my first email on
this subject I argued for SG, but now I'm thinking perhaps the destination
address selector in inbound processing should be B (the destination address
after routing header 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: Mon, 22 Feb 1999 20:35:47 -0800 (PST)

> point you are trying to make.

Yes I agree, but only that it should not consider SG as part of the
selector, but the final destination, unless policies have capabilties
to include intermediate destinations as part of the selector list. 
I guess this is implementation dependent.

The point I was trying to make in my first mail, was that if A
is communicating with D via B and C, the resulting packet
looks like

	IPv6 hdr - src A, dst B
	Routing hdr - segs left = 1, C, D
	Transport hdr

Then it does IPSEC processing. Depending on the policy (irrespective
of how detailed the selector list) lookup, chooses a policy, which
directs it to either do tunnel mode IPsec with an SG or transport
mode IPSEC with D.

In the 1st case, the packet will look like :
	
	IPv6 hdr - src A, dst SG
	ESP Tunnel mode with SG
	IPv6 hdr - src A, dst B
	Routing hdr - segs left = 1, C, D
	Transport hdr

In the later case, it will be

	IPv6 hdr - src A, dst B
	ESP transport mode with D
	Routing hdr - segs left = 1, C, D
	Transport hdr

The secure gateway processes the 1st case by doing inbound IPSEC, 
processing the ESP header. Next it processes the routing header 
and forwards the packet to C.

In the 2nd case, if SG had an IPSEC policy that expected anything
received on the interface this packet is received as ESP tunnelled,
then it would drop the packet.

All I was trying to say is that a routing header should not mean that
IPSEC outbound processing be done twice, one with selector D, and next
with selector B. IPsec processing should be done once, with both B and
D as part of selectors. Or only D, if selectors containing intermediate
dests are not supported.

So when a mobile node moves beyond a SG, how does a correspondent know
that and hence configures a policy to do IPSEC tunnel mode with SG ?
Rather, I would assume that such SGs who expect mobile nodes to enter
their domain, would have policies which would allow traffic which is
IPSECed (by the presence of IPSEC headers) but not destined for them.

Quaizar

---

From: Steve Deering <[email-masked]>
Date: Tue, 23 Feb 1999 06:35:42 -0800

At 8:06 PM -0800 2/22/99, Richard Draves wrote:
> routing header should do inbound & outbound IPsec processing, ...

Rich,

I've only had a chance to skim these messages, but it occurs to me that
some might be confused by your phrase "do IPsec processing", thinking
that it means "process the IPsec header(s)", when what you really mean
is "perform security policy enforcement", e.g., verify that the
packet under consideration arrived via a secure tunnel, or encapsulate
the packet in a secure tunnel for the next leg of its route, depending
on arrival/departure interface.  An IPsec header itself should never be
"processed" by anyone other than its original source and its final
destination.

Steve