Subject: RE: [mobile-ip] question on protecting MN - HA communication

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 9 Oct 2002 21:20:14 +0200

> => Understood, but given the rarity of this message
  > > compared to normal traffic and the unnecessary assumptions
  > > that it makes, I'm not too sure that it's worth it.
  > 
  > I forgot something. the same procedure is followed for
  > IPsec protected reverse tunneled payload traffic (sec 7.3.4).
  > in that case, it wont be a rarity anymore.

=> If BW is an issue (of course it is!) then 
Header compression will compress the HAO. 

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 9 Oct 2002 21:27:22 +0200

Sorry I'm replying to myself.

  >   > the only assumption here is the existense of this API. and 
  >   > in the draft, we are not leaving it as an assumption. we are 
  >   > requiring it. almost always, the SA database exists in the 
  >   > kernel. so, it shouldnt be difficult to have this API.
  > 
  > => I think there is a bigger assumption and that is
  > the SPD will be processed after the route lookup.
  > I don't think this routing information is always
  > available when the SPD is processed. 

=> I just want to make it clear that I don't have a
problem with assuming an internal API that changes 
the TEP dynamically. I was trying to show that there
is another (possibly unnecessary?) assumption (above).

Hesham

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 9 Oct 2002 15:47:35 -0700

Hesham,

> 
> 
>   > >   > notice the home address option (24 bytes). this 24 bytes
>   > >   > overhead is removed by making the tunnel interface as one of
>   > >   > the selectors and by changing the gateway address 
> (towards the
>   > >   > MN) whenever the MN moves and changes its CoA. the gateway
>   > >   > addresses for the ESP tunnel are MN's CoA and HA's address.
>   > > 
According to RFC2401, (section 4.4) there is one SPD/SAD per Ipsec
enabled
interface. Implementations can choose to have just one SPD/SAD per
system
also. Is your concern that there are implementations where the interface
is not known when SPD is consulted ? There could also be implementations
where
all traffic going through the tunnel will be Ipsec protected. In this
case, "SPD"
is not consulted until the interface is known.

-mohan

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 10 Oct 2002 00:50:18 +0200

Mohan, 
 
> available when the SPD is processed. 
According to RFC2401, (section 4.4) there is one SPD/SAD per Ipsec enabled 
interface. Implementations can choose to have just one SPD/SAD per system 
also. Is your concern that there are implementations where the interface 
is not known when SPD is consulted ? There could also be implementations where 
all traffic going through the tunnel will be Ipsec protected. In this case, "SPD" 
is not consulted until the interface is known.  
 
=> Yes, this is my concern. Remember that a MN, by definition,
has more than one interface: The tunnel interface to the HA and
other interfaces that it might have. 
 
Hesham

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 9 Oct 2002 16:55:17 -0700

-----Original Message-----
	From: Hesham Soliman (EAB)
[mailto:[email-masked]] 
	Sent: Wednesday, October 09, 2002 3:50 PM
	To: Mohan Parthasarathy; Hesham Soliman (EAB); Vijay Devarapalli
	Cc: [email-masked]
	Subject: RE: [mobile-ip] question on protecting MN - HA
communication

	Mohan, 

	> available when the SPD is processed. 
	According to RFC2401, (section 4.4) there is one SPD/SAD per
Ipsec enabled 
	interface. Implementations can choose to have just one SPD/SAD
per system 
	also. Is your concern that there are implementations where the
interface 
	is not known when SPD is consulted ? There could also be
implementations where 
	all traffic going through the tunnel will be Ipsec protected. In
this case, "SPD" 
	is not consulted until the interface is known.  

Are you saying that as there are more than one interface on the MN, the
assumption that interface is known at the time of consulting SPD is
not valid ? Could you elaborate ?
 
-mohan

	Hesham

---

From: Marc Hasson <[email-masked]>
Date: Wed, 9 Oct 2002 18:38:30 -0700 (PDT)

In regards to this original reference...

   mobile node SPD OUT:
     - IF interface = tunnel to home agent &
       source = home address & destination = any & proto = MH
       THEN CREATE ESP TUNNEL SA: gateway = home agent &

Hesham wrote and Vijay replied:

 > > => That's not clear, do you mean that you can remove
 > > the first condition (tunnel i/f) and keep this as it
 > > is? I don't think so, because the destination cannot
 > > be left to "any". Note that this check is done
 > > _before_ the packet is tunnelled to the HA.
 > 
 > ah! I think you are right.

I'm not as sure he is.  The cited policy entry comes from section 7.3.2
BUT the entries in 7.3.1 must be applied first just as in the analagous
manual configuration sections 7.2.2 and 7.2.1.  Right?  So the "any"
destination with MH is fine, that is proper policy to send to a CN for
RR HOTI signaling IPsec-protected through the HA.  Otherwise a specific HA
destination would already have been selected by a 7.3.1 policy for that
packet.

   -- Marc --

---

From: Marc Hasson <[email-masked]>
Date: Wed, 9 Oct 2002 19:00:05 -0700 (PDT)

Vijay,

 > the draft says (somewhere), implementations are free to
 > choose whatever mechanism they want internally as long
 > as the packets on the wire look as described in the draft.

I thought you were right immediately, those words sounded familiar
from this draft.

But it took me a while to find where (end of first paragraph in Section
8, I didn't see others but could have missed them) and that seems to
apply only to the actual internal processing steps of that section.  I
appreciate your feedback below but believe many readers of the spec
would still think tunnel interfaces were required given all the
references to it.  They might also be concerned that tunnel interfaces
were required given the Section 6 requirements section that starts with
the "mandatory rules" ... to "guarantee sufficient security" in
conjunction with the MUST for SPDs on a tunnel interface mentioned
further down in that section.

My apologies if this sounds "picky", you guys have clearly put out a
lot of effort trying to get all these rules straight.  And your feedback
so far has made it clearer that all is probably fine as long as we all
agree on the packet headers/formats.

Thanks.

   -- Marc --

 > 
 > Marc Hasson wrote:
 > 
 > > Is the term "tunnel interface" mandatory and to be taken literally for
 > 
 > no.
 > 
 > > I guess my summary point is that generation of outgoing tunnel headers
 > > or inspection/validation of incoming ones doesn't require the
 > > implementation of an actual "tunnel interface" construct.  I've
 > > implemented tunneling multiple ways for past projects, each approach has
 > > had its own pros/cons.  Implementers should be free to choose unless there
 > > is some (currently unclear to me here) requirement for a specific approach.
 > 
 > absolutely.
 > 
 > Vijay
 >

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 10 Oct 2002 11:53:41 +0200

> I see your concern.
  > but I always thought it is possible to have an SPD entry 
  > which says "if packets go through a particular interface, 
  > apply SA". so what does a typical IPsec implementation do 
  > in such a case?
  > 
  > anyway, the new text in the HA-MN IPsec draft says
  > 
  >      - We have chosen to require policy entries that are 
  > specific to a
  >      tunnel interface. This means that implementations have 
  > to regard
  >      the Home Agent - Mobile Node tunnel as a separate interface on
  >      which IPsec SPDs can be based.
  > 
  > this is under implementations considerations. 

=> ok. I completely understand the logic, but I
can't see a great benefit from it really. 

  > ps: we need to resolve this soon.

=> Yes, let's see what others think.

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 10 Oct 2002 11:55:48 +0200

=> Yes, that's what I'm saying. The route lookup is not 
always known when the SPD is processed (for outgoing
packets). 
 
Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 11 Oct 2002 15:32:49 +0200

Marc,

  > > 
  > > => My statement was on how to distinguish between MH
  > > sent to the CN directly (COTI, BU ...etc) and MH
  >                            ^^^^
  > Did you mean HOTI here?

=> No, HOTI is not sent to the CN.

  > 
  > > packets going to the HA. The policy is fine for
  > > MH packets going to the HA but I don't see how
  > > it can be used as is to distinguish between CN
  > > packets with MH and HA packets with MH, if the
  > > check on the tunnel i/f is removed.
  > 
  > I don't see the confusion, perhaps you can show me what
  > I'm missing.  The 7.3.1 policies will take care of the MN
  > MH packets going to/from the HA, agreed.  

=> I think you're putting my comment in a completely
different context. This particular comment was made
in response to Vijay's. I was wondering why the 
check on the tunnel interface is needed (to distinguish
MH traffic to the CN from that sent to the HA?)
Vijay said no and I disagreed.... the reasons are
in that email. Basically if you remove the check
for the tunnel i/f then you can't use the packet
formats or SPD policies in the current draft
(for HOTI). 

Please see the original correspondence with
Vijay.

Hesham

---

From: [email-masked]
Date: Mon, 14 Oct 2002 15:33:20 +0300

Vijay Devarapalli wrote:
>      - We have chosen to require policy entries that are specific to a
>      tunnel interface. This means that implementations have to regard

While RFC2401 says that "a nominally separate SPD must be provided for each IPsec enabled interface", I don't think this was supposed to cover IPsec tunnels created with IPsec itself.

I have also a question on the SPD rule referred by this thread:

       mobile node SPD OUT:
         - IF interface = tunnel to home agent &
           source = home address & destination = any & proto = MH
           THEN CREATE ESP TUNNEL SA: gateway = home agent &
                                      local phase 1 identity = user1

Assuming that "tunnel to the home agent" is just any interface (as seen by IPsec), wouldn't the policy rule create ANOTHER tunnel *within* the "tunnel to the home agent" interface (2 levels of inner headers)? If not, then why not? (it should be clear that the above rule should create another layer of IP tunneling, if the interface "selector" would be e.g. "eth0").

The following should produce the wire-format specified in the draft:

       mobile node SPD OUT:
         - IF source = home address & destination = any & proto = MH
           THEN CREATE ESP TUNNEL SA: gateway = home agent &
                                      local phase 1 identity = user1

As per RFC 2401 (see the NOTE: on page 32) an appropriate source address for the outer header will be automatically selected (should be CoA). (The outer source address is ignored by IPsec).

And as already noted in another message, a more specific rule for the HA destined MHs before the above rule should take care of the MN-HA signaling.

However, the above rule alone should work for BOTH MN-HA and MN-any signaling protection, reducing the number of required SAD/SPD entries in both MN & HA. It works because the outer source address is ignored by the IPsec in the HA, and can thus be a new CoA without any problems.

Regards,

	Jarno

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 15 Oct 2002 10:13:37 -0700

Jarno,

> While RFC2401 says that "a nominally separate SPD must be 
> provided for each IPsec enabled interface", I don't think 
> this was supposed to cover IPsec tunnels created with IPsec itself.
> 
If you think the tunnel as another interface in your system and read
that statement, I am not sure why it does not cover this case. It
is just an implementation detail. ESP tunnel mode SA can be implemented
as "tunnel interface + ESP SA".

> Assuming that "tunnel to the home agent" is just any 
> interface (as seen by IPsec), wouldn't the policy rule create 
> ANOTHER tunnel *within* the "tunnel to the home agent" 
> interface (2 levels of inner headers)? If not, then why not? 
> (it should be clear that the above rule should create another 
> layer of IP tunneling, if the interface "selector" would be 
> e.g. "eth0").
> 
ESP tunnel SA says that the packet is encapsulated and the policy checks
should happen with inner header. And it is implemented with the help of
an
tunnel interface for the encapsulation part.  

> As per RFC 2401 (see the NOTE: on page 32) an appropriate 
> source address for the outer header will be automatically 
> selected (should be CoA). (The outer source address is 
> ignored by IPsec).
> 
That would add an extra HAO which is not needed when we are tunneling
to HA.

-mohan

> And as already noted in another message, a more specific rule 
> for the HA destined MHs before the above rule should take 
> care of the MN-HA signaling.
> 
> However, the above rule alone should work for BOTH MN-HA and 
> MN-any signaling protection, reducing the number of required 
> SAD/SPD entries in both MN & HA. It works because the outer 
> source address is ignored by the IPsec in the HA, and can 
> thus be a new CoA without any problems.
> 
> Regards,
> 
> 	Jarno
> 
>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 15 Oct 2002 13:15:09 -0700

Vijay,

> > Mohan Parthasarathy wrote:
> > 
> > Vijay,
> > 
> > If we go by the IETF maxim "be liberal in what you accept", 
> I am not 
> > sure whether we can drop the packet :-)
> > 
> > From your original email,
> > 
> > IPv6 header (source = care-of address, destination = home agent)
> >    Dst Opts Hdr
> >       HAO
> >    ESP header
> >    IPv6 header (source = home address, destination = correspondent
> > node)
> >    Mobility Header
> >       Home Test Init
> > 
> > We want to disallow this format on the wire i.e., whenever 
> a packet is
> > 
> > tunneled to the home agent, HAO is not useful at all, so 
> why add it ? 
> > If we don't look at the implementation details, this sounds 
> reasonable
> > 
> > to me. But this is the format used by the original MIPv6 
> draft as far 
> > as I can tell. It was not clearly documented but the details about 
> > processing the HAO before processing the Ipsec etc. would indicate 
> > that. So, there might be already some implementations doing
> > this. Don't you think we would be better off documenting 
> this instead
> > of disallowing this ?
> 
> IMO, it does not fit into the draft. the draft assumes an 
> IPsec tunnel interface between MN and HA, with SPDs based on this 
> tunnel interface.
> 
I am okay with this as long as we can get everyvody agree on what
we would do if the packet format does not fit the above.

> moreover, the ESP header cannot protect the HAO destionation 
> options header.
> 
correct. Actually the HAO option is of no use in this case, even if it
is
corrupted, it does not matter. The outer header will get thrown away as
part of decapsulation i.e the receiver processes the Home Address option
before the Ipsec processing, decrypts the packet, checks the inner
address
(home address) with the SAD selector, packet is decapsulated and we are
done.
So, going by this, you don't even have to say anything in the document
regarding
this. HA has to process the HAO like it is described in the base mipv6
draft.
(if we use AH, then it is different which we are not interested in I
guess).

-mohan

> it would be better to leave it out.
> 
> Vijay
>

---

From: [email-masked]
Date: Wed, 16 Oct 2002 13:13:35 +0300

> as "tunnel interface + ESP SA". 

I see this, but another implementation choice could be that the tunnel is created during the SA setup based on the policy entries (i.e. SPD says tunnel mode: create tunnel, or transport mode: do not create tunnel). Therefore when the policy is first checked (before the SAs have been created), the tunnel may not exist at all. The SPD entries causing the tunnel creation are not specific to the non-existing tunnel, but all packets being sent/forwarded on the specific interface are checked against the same SPD entries.

> should happen with inner header. And it is implemented with 
> the help of an 

Does IPsec mandate "tunnel interface" implementation? Isn't it possible that e.g. on a security GW (or a Home Agent) there is a clear separation with "interfaces" and the possibly thousands of tunnel end-points?

To rephrase my question above: If IPsec SDP entry will create a new tunnel end-point, wouldn't the above policy create a tunnel within a tunnel? Or can IPsec tunnel-mode be used only on tunnels being somehow configured already independently of the SPD entry?

> That would add an extra HAO which is not needed when we are tunneling 

IPsec would not be adding any extra HAO. I have understood Mobile IPv6 would add a HAO only if the packet being sent out has a matching binding entry in the Binding Update List. On the tunneled packet the (outer) source address is NOT the home address, so there should not be any matching entry to be found.

IF Mobile IPv6 is nonetheless adding a superfluous HAO, maybe the Mobile IPv6 spec should be fixed so that the unnecessary HAO will not be added?

	Jarno

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 16 Oct 2002 14:09:25 -0700

> I see this, but another implementation choice could be that 
> the tunnel is created during the SA setup based on the policy 
> entries (i.e. SPD says tunnel mode: create tunnel, or 
> transport mode: do not create tunnel). Therefore when the 
> policy is first checked (before the SAs have been created), 
> the tunnel may not exist at all. The SPD entries causing the 
> tunnel creation are not specific to the non-existing tunnel, 
> but all packets being sent/forwarded on the specific 
> interface are checked against the same SPD entries.
> 
Sure, it is possible. But in the MN-HA case, you always have the
tunnel e.g. for sending data packets which may not be protected with
Ipsec.

> Does IPsec mandate "tunnel interface" implementation? Isn't 
> it possible that e.g. on a security GW (or a Home Agent) 
> there is a clear separation with "interfaces" and the 
> possibly thousands of tunnel end-points?
> 
Ipsec does not mandate tunnel SA to be implemented with tunnel
interfaces. What you say is surely possible.

> To rephrase my question above: If IPsec SDP entry will create 
> a new tunnel end-point, wouldn't the above policy create a 
> tunnel within a tunnel? Or can IPsec tunnel-mode be used only 
> on tunnels being somehow configured already independently of 
> the SPD entry?
> 
May be we should clarify on what the above text was trying to
say. In this specific case, there is a tunnel between MN-HA
and similary HA-MN. You need Ipsec to protect the traffic
selectively. Protection required is ESP tunnel mode SA. 

> IPsec would not be adding any extra HAO. I have understood 
> Mobile IPv6 would add a HAO only if the packet being sent out 
> has a matching binding entry in the Binding Update List. On 
> the tunneled packet the (outer) source address is NOT the 
> home address, so there should not be any matching entry to be found.
> 
> IF Mobile IPv6 is nonetheless adding a superfluous HAO, maybe 
> the Mobile IPv6 spec should be fixed so that the unnecessary 
> HAO will not be added?
> 
Re-reading the section on "Packet Processing" of mobile node (section 
11.2.1 in my copy), under reverse tunneling section, it does not seem
to add an home address option. Perhaps, Vijay can clarify this. At least
I don't see the use for it.

-mohan