Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup port in IPv6"draft]

From: Richard Draves <[email-masked]>
Date: Fri, 3 Nov 2000 11:09:45 -0800

> > > When calculating the AH checksum, the mobile node performs
> > > the calculation with all data in place.  This means that,
> > > during the calculation, the Care-of Address might be in the
> > > Source IP address field of the IPv6 header, and then the home
> > > address would be in the Home Address destination option.

This is my preference. Some implementations need to treat packet data as
read-only and can't actually switch or exchange addresses in the packet.

It's really not too hard to pass along a bit of additional data with the
packet, essentially a pointer to the logical source address, which initially
points to the source address in the IPv6 header and later points to the
address in the Home Address option.

> > 3. Process AH naturally. Security Association is chosen
> based on the source
> > address of the packet.

I've seen this opinion in several messages and I don't understand it. When
processing an AH or ESP header, the security association is chosed based on
the *destination* address, the SPI, and the IPsec header type. See section
5.2.1 of RFC 2401.

Therefore, I don't why it's advantageous to process the Home Address option
before the IPsec header. I would appreciate it if someone could explain this
again.

You do need to know the Home Address when consulting the Security Policy
Database, but that would typically happen later. To consult the SPD, you
also need to know the upper-layer protocol (eg TCP or UDP) and port numbers.

Thanks,
Rich

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 3 Nov 2000 12:56:40 -0800

Hi,

See my comments below

> read-only and can't actually switch or exchange addresses in the packet.

You never do AH checksum calculation on the original packet. You need
to zero out fields that are mutable. You need to change those fields that
are mutable but predictable. You most often have to create another
mbuf or a text string and calculate the AH checksum on it.

> address in the Home Address option.

And where would you put such a pointer?

> the *destination* address, the SPI, and the IPsec header type. See section

Look at bullet 2 of section 5.2.1 of RFC 2401.

           2. Use the SA found in (1) to do the IPsec processing, e.g.,
              authenticate and decrypt.  This step includes matching the
              packet's (Inner Header if tunneled) selectors to the
              selectors in the SA.  Local policy determines the
              specificity of the SA selectors (single value, list,
              range, wildcard).  In general, a packet's source address
              MUST match the SA selector value.  However, an ICMP packet
              received on a tunnel mode SA may have a source address.....

SA selection is not finished with step 1. Note the MUST in the above
paragraph. I would be happy if the packet's source address is the
Home address of the mobile node at this point. At this point we
havent reached the SPD lookup yet.

Regards
Vijay

---

From: Francis Dupont <[email-masked]>
Date: Sat, 4 Nov 2000 16:31:20 +0100

=> it is really a matter of taste... As far as I know nobody strongly objects
against a solution or the other.

=> I agree the inbound SA lookup uses only this triple (with the receiving
interface for scoped IPv6 destination address but we can say the zone is
a property of the address, ie. it is just a pitfall for implementors :-).
But it is not true for the outbound processing and SAs have a source
address (clear in IKE specs) and maybe a proxy address (cf PF_KEY).
These addresses can be checked by the inbound code:
 - no check
 - check before processing (paranoia?)
 - check after processing
I know KAME doesn't check the source address and OpenBSD checks it after
processing (and check the inner source with the proxy address for tunnels).
Old NRL code checks it with the found SA source and proxy addresses in
the lookup routine... The three options are present in the first three
implementations have looked for!

Then for paranoid IPsec implementations the home address should be before
the IPsec headers and for firewalls (paranoid by definition :-) it should
be available in clear text in all packets, including fragments.

=> it makes paranoid IPsec correspondent (ie. at receiving side)
implementations easy to implement and it makes firewall people happy.

=> I agree. This argument (SPD will check anyway) can be used if you'd like
to banish paranoid IPsec implementations... I believe to check the source
address in the SA processing is too restrictive (I've got some comments
about my I-D for home tunnels because of this :-) then I'll support you?

Note that to have a source address in a SA is still useful (our concern
is about a bad? usage of it), IKE builds a pair of SAs and the source
of one SA is the destination of the other. For mobile IPv6 SAs are
between the home agent (with its unicast address known/used by the mobile)
and the mobile node (with its home *stable* address). If the second
address is wrong BAs will be wrong.

Regards

[email-masked]

PS: the good news is this works (we did a secure BU/BA exchange at the ETSI
bake-off), the bad news is you need (to be) an IPsec expert in order to
make this work... IKE configuration for instance is a nightmare.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 4 Nov 2000 17:19:04 +0100

paragraph.

=> I don't know exactly how to deal with this MUST (introduced by
a "in general" ???). The source address of the packet with the IPsec
header is or:
 - explicitely protected by AH
 - implicitely protected by the successfull processing according to
   the SA (ie. one can't impersonate the real source because it doesn't
   know shared secret(s))
then it is clearly for tunneled packets because it applies to the
*inner* source address (1). Note the text doesn't give the name of the SA
selector, according to RFC 2401 or RFC 2409 it is "source", according to
RFC 2367 it is "proxy" and in RFC 2409 there is a (not) clarification
about "acting as a client negotiator on behalf of another party"...

   I would be happy if the packet's source address is the
   Home address of the mobile node at this point.

=> even if the check is based on a misinterpretation of RFC 2401
I agree with you that we need the home address there in the real world!

   At this point we havent reached the SPD lookup yet.

=> SPD processing is clearer because it is only on the inner header.

Regards

PS 1: the quoted packet's source address is the inner one because at
the head of the enumeration there is: "Note that the selector checks
are made on the inner headers not the outer (tunnel) headers."

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 6 Nov 2000 10:30:11 -0800

> are made on the inner headers not the outer (tunnel) headers."

Inner header if the packet is tunneled. Not otherwise.

Vijay