Subject: [Mip6] comments/questions on draft-ieft-mip6-ikev2-ipsec-02.txt

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 31 Aug 2005 16:30:39 +0900

Hello,

I read draft-ieft-mip6-ikev2-ipsec-02.txt and had following
comments/questions.  I support this draft and think it's useful.

Technical Comments:

- Basically I agree that removal of dependency on per-interface SPD
  entry is a good thing which can be achieved by having MH type in
  the traffic selector.  But I see concern about interoperability
  issue which may come up when the security policy settings of the
  mobile node and home agent are slightly different.  For instance,
  suppose if the home agent does not support RFC2401bis and sets
  only MH(135) in the protocol field while the mobile node supports
  RFC2401bis and specifies MH type in its selector of the SP entry.
  Obviously such operation will fail.  The mobile node will fail to
  receive IPsec tunneled mobility signals (e.g. BA or CoTI) from its
  peer who is also a mobile node.  This problem was seen in the past
  interop event.  So, I would suggest to add some texts in Section
  4.3 to avoid having interoperability problem.

  o  The home agent and mobile node MUST have equivalent settings of
     security policy in terms of granularity of upper layer protocol
     specified in the traffic selector.

- Section 6.1.2, I found that some of the selector information does
  not contain src addr, dst addr (or both).  Is there any specific
  reason for this ? In addition, I found description of inner src/dst
  addr information as a part of SPD entry but is it needed ?
- Section 6.1.3, similar to above, some of the src/dst address is
  missing in the selector info.
- First paragraph of Section 8 (Dynamic Home Address Configuration):

   The mobile node can dynamically configure a home address by including
   a Configuration Payload in the IKE_AUTH exchange, with a request for
   an address from the home link.  The mobile node should include an
   INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST Payload.  The
   mobile node MAY also include the INTERNAL_IP6_SUBNET attribute if it
   wants to obtain information about the IPv6 prefixes on the home link.

  IMHO, s/should/SHOULD/ in the second sentence seems reasonable.

- Section 8 (Dynamic Home Address Configuration), this may be outside of
  scope of this draft but I wonder how could the initiator (mobile node)
  starts initial IKE exchanges in dynamic configuration scenario.  In
  normal case (where HoA and HA address is configured beforehand), BU
  would be the triggering packet of the IKE negotiation.  But how about
  in this (dynamic HoA config) case ?  And what would be the content
  of TSi in the IKE_AUTH exchange ?
- Section 9 (Security Considerations), the last sentence says "The Home
  Agent MAY store the assigned home address in the SPD entries created
  for the mobile node." To me, this sounds a bit weird.  I assume that
  the home agent basically manages SPD entries per mobile node.

Editorial Comments:

- I think all the "SPD-I" that appear in the document should be
  replaced with "SPD-S", if I understand the RFC2401bis terminology
  correctly.  No matter which direction is, all the SPD entries that
  we are dealing with in MIPv6 are of secure traffic.
- Use of term "Home Agent" or "home agent" (same applies to mobile node)
  should be consistent throughout the document.

Regards,
Shinta

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Francis Dupont <[email-masked]>
Date: Wed, 31 Aug 2005 16:49:43 +0200

In your previous mail you wrote:

=> there was a long discussion about SPD mismatch between IKE peers
in the IPsec mailing list. It seems the TS exchange helps to detect
this kind of problems but IMHO even it should be common sense we can
repeat the policies at each side must match.
(PS: TSs are not enough, for instance they don't always show if a
SA pair can be shared... IMHO their indications are mainly negative,
and of course they never repair misconfigs).

=> the inner addresses are part of the selectors (if the abstract
syntax for SPD entries was used, this kind of questions would be
avoided).

=> I believe the answer is in the IKEv2 specs (at least I am sure for
the TSi!) so the HoA before the assignment is ::? Of course the BU
should not be cached...
If someone using internal address config with IKE has more details?

=> I am afraid this is just a consequence of dynamic home address
assignments and in fact the issue is more complex because authorization
(not only policies) must be updated according to assignments.

BTW when a mobile node returns to home, the home agent (i.e., its
MIPv6 code) has to delete/disable some corresponding SPD entries,
and (worse) it has to readd/enable them when the mobile node is
detected as in visit. How to manage this when the MIPv6 code crashes,
the home agent reboots, etc, is still an open question in SHISA
(the KAME MIPv6 code)...

   Editorial Comments:

=> I've already signaled this point (:-).

Thanks

[email-masked]

---

From: "James Kempf" <[email-masked]>
Date: Wed, 31 Aug 2005 09:34:04 -0700

-----> - Section 8 (Dynamic Home Address Configuration), this may be outside 
of
>  of TSi in the IKE_AUTH exchange ?

draft-ietf-mip6-bootstrapping-split-00.txt discusses this somewhat. Perhaps 
more detail is necessary.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 31 Aug 2005 15:45:09 -0700

>   4.3 to avoid having interoperability problem.

I dont have anything to add to what Francis said. we can't do
anything about this.

>      specified in the traffic selector.

this sounds obvious, right?

>   reason for this ? 

if they are exlcuded, it means "any".

In addition, I found description of inner src/dst
>   addr information as a part of SPD entry but is it needed ?

I think so. the SPD entries say create tunnel mode SAs. but we
need to specify which address to use for the inner src, outer src,
inner dst, and outer dst. right?

>   IMHO, s/should/SHOULD/ in the second sentence seems reasonable.

why? the whole section is optional. one of the requirements in
Section 4.1 says

    o  The Home Agent and the mobile node MAY support remote
       configuration of home address as described in Section 8.

if the MN wants to use this mechanism to configure a HoA, then its
got to include the INTERNAL_IP6_ADDRESS attribute in the CFG_REQUEST 
payload. thats why the lower case 'should'.

>   in this (dynamic HoA config) case ?

good question. I dont have a good answer. starting up the mip6
daeomn? the lack of a HoA? could be anything.

   And what would be the content
>   of TSi in the IKE_AUTH exchange ?

the same as TSi in a regular IKEv2 exchange used with a
configuration payload. nothing MIP6 specific.

>   the home agent basically manages SPD entries per mobile node.

you are right. you may not necessarily have an SPD entry per
mobile node. the idea is that the MN requests and gets a HoA
assigned. later on it tries to re-use the same HoA and creates
new security associations. the HA must check if the MN
(identified by some kind of identity, NAI, FQDN, etc) is
allowed to use the HoA. you could store the state somewhere
else instead of the SPD entries to achieve the same.

>   we are dealing with in MIPv6 are of secure traffic.

I am not sure about this. lets say a MN sends an unprotected
BU. the Home Agent receives this. since there is no IPsec
protection on this, it will hit the SPD-I. what should the
HA do with this packet. silently drop it or trigger IKEv2
negotiation? if silently drop, then what you say is true.
if trigger IKEv2 negotiation then don't you need something
like the following?

         home agent SPD-I:
           - IF destination = home_agent_1 & proto = MH & mh_type = BU
             Then use SA ESP transport mode
                             IDr = user_1, IDi = home_agent_1,
                             TSr = home_address_1

>   should be consistent throughout the document.

I have tried to use "Home Agent" and "mobile node" throughout.
will fix wherever needed.

Vijay

---

From: Shinta Sugimoto <[email-masked]>
Date: Thu, 01 Sep 2005 11:25:31 +0900

Hello Francis,

On Wed, 31 Aug 2005 16:49:43 +0200

> and of course they never repair misconfigs).

OK. TS negotiation seems to be (to some extent) helpful to detect the
mismatch of security policy between the peers.

> syntax for SPD entries was used, this kind of questions would be

Ahh, yes, inner address is certainly part of traffic selector. So
why not illustrate the SPD entry like:

        mobile node SPD-S:
          - IF source = home_address_1 & proto = MH & mh_type = HoTi
            Then use SA ESP tunnel mode
                            IDi = user_1,
                            outer src addr = coa,
                            outer dst addr = home_agent_1

rather than

        mobile node SPD-S:
          - IF proto = MH & mh_type = HoTi
            Then use SA ESP tunnel mode
                            IDi = user_1,
                            outer src addr = coa,
                            outer dst addr = home_agent_1,
                            inner src addr = home_address_1

?

> If someone using internal address config with IKE has more details?

(pls correct me if I am wrong) I checked the Section 2.19 of IKEv2 spec
and I believe the procedure described in the section applies to MIPv6
dynamic config scenario.  IRAC (MN in this case) consults IRAS (HA)
for the inner address (HoA).  According to the examples given in Section
2.19, it seems that you are right.  TSi included in the message from
initiator to responder just contains :: in MIPv6 case.

> (not only policies) must be updated according to assignments.

Right. If dynamic home address assignment is performed, I believe SPD
entries should also be updated dynamically.

> the home agent reboots, etc, is still an open question in SHISA

Yes, as mentioned in the draft, the tunnel SPD entries should be
torn down (or deleted).  How to do this is an implementation issue.

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Thu, 01 Sep 2005 12:15:04 +0900

Hello Vijay,

On Wed, 31 Aug 2005 15:45:09 -0700

> this sounds obvious, right?

Yes, but I am sure there will be an interoperability issue comes up.
IMHO, any effort which may help to avoid having miscofig should be made. 

> if they are exlcuded, it means "any".

why any? home_address_1 is already specified as an inner address.
I believe home_address_1 should be given in the source/destination of
the selector information.

> inner dst, and outer dst. right?

Yes.

Sorry, my question may have been unclear. IMHO, inner src/dst is needed
as a part of SPD entry as a selector.  To me, the illustration was
a bit confusing because the inner src/dst was given as if they were
part of SA entry.

> payload. thats why the lower case 'should'.

OK, I see.

> configuration payload. nothing MIP6 specific.

I see.  It seems that this is exactly the case which is presented
in IKEv2 spec where IRAS procures inner address for IRAC.
IRAS=HA, IRAC=MN, inner address=HoA, in MIPv6 case.

> else instead of the SPD entries to achieve the same.

OK, understood.

>                              IDr = user_1, IDi = home_agent_1,

Mmm, it seems that we have different understanding on SPD-I,O,S.
If I understand 2401bis correctly, the distinctions of SPD-I,O,S
entries are dependent on processing info of the security policy
(DISCARD, BYPASS, PROTECT) entry.  SPD-S entry is applied to the traffic
which is expected to be protected by IPsec.  SPD-I,O entry is
applied to the traffic which is expected to be bypassed/discarded.
"I" for inbound, "O" for outbound traffic.

In your example above, "Then use SA ESP transport mode" means PROTECT,
so, I believe the SPD entry is categorized as SPD-S.

Regards,
Shinta