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

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 01 Sep 2005 16:21:46 -0700

I am going to only respond on points where we don't yet
have an agreement.

Shinta Sugimoto wrote:

>>>- 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 ? 
>>
>>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.
> 
> 
>>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?
> 
> 
> Yes.
> 
> Sorry, my question may have been unclear. IMHO, inner src/dst is needed
> as a part of SPD entry as a selector. 

is the Home Address match really needed to identify that
a packet with a BU must be protected?

the following is enough to identiy the HoTi traffic and trigger IKEv2
negotiation for tunnel mode ESP.

         mobile node SPD-S:
           - IF proto = MH & mh_type = HoTi
             Then use SA ESP tunnel mode
                        .............

having the home address as the selector for matching traffic against
policies does not add anything.

> To me, the illustration was
> a bit confusing because the inner src/dst was given as if they were
> part of SA entry.

I think I know the cause of the confusion. when I say

         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

this means that if there is a any traffic where protocol == MH
and mh_type == HoTi, then create an ESP tunnel mode SA with
IDi = user_1, outer src address = CoA, outer dst addrr =
home_agent_1 and inner src addr = home_address_1. maybe I
need to replace "Then use SA" with "Then create SA" throughout
in section 6.1. what do you think?

>>>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.
>>
>>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
> 
> 
> 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.

lets confirm this with someone who knows IPsec better. I have created
an issue (issue 32) for this at 
http://www.mip4.org/issues/tracker/mip6/issue32

Vijay

> Regards,
> Shinta

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

---

From: Shinta Sugimoto <[email-masked]>
Date: Thu, 08 Sep 2005 19:06:19 +0900

Hello Vijay,

Sorry for the delay. Please find my comments inline.

On Thu, 01 Sep 2005 16:21:46 -0700

>              Then use SA ESP tunnel mode

Ok, I think I understand your point. I am fine with not specifying
the home address in selector in above case.

> in section 6.1. what do you think?

(my comments below is actually an answer to issue #23, though)

Hmm. I think I understand your logic.  But I still think that the
above representation of SPD is not common to everyone.  Having read
the rfc2401bis, I concur Francis's suggestion to use ASN.1 notation
for the illustration of SPD examples in order to avoid confusion.
Probably it needs more spaces for the figure, but those could be
moved to Appendix I think.

Regards,
Shinta

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 15:52:56 +0200

In your previous mail you wrote:

=> note that Stephen gave the pointeur to the right section (4.4.1.3)
of rfc2401bis (put OPAQUE on the other side).

   >              Then use SA ESP tunnel mode
   
=> I disagree, the home agent can be "home agent" only on some interfaces.

=> I am not. Underspecifying a SPD is a sure way to disasters.

   >                              inner src addr = home_address_1

=> the inner address is in the SPD.

   > in section 6.1. what do you think?
   
=> the correct term is "Then protect with SA"

   
=> my current proposal is to have a standardizing annex with the ASN.1
description.

Thanks

[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 08 Sep 2005 12:07:18 -0700

> => I disagree, the home agent can be "home agent" only on some interfaces.

the source address for the tunneled HoT message is invariably
the same as the HA's address that is known to the mobile node.
otherwise the SPD entries on the MN while receiveing the
tunneled HoT messages will discard the packet.

in case of the mobile node, I want to make it possible for the
MN to use multiple home addresses, temporary home addresses
and auto-configued home addresses. hard-coding the MN's HoA
in the SPD entries will only create problems.

> => my current proposal is to have a standardizing annex with the ASN.1

again, I dont think the ASN.1 description is easy to read.
and I haven't seen it used anywhere else apart from 2401bis
appendix.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 08 Sep 2005 12:08:17 -0700

> the home address in selector in above case.

okay. I will close issue 33 as rejected.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Fri, 09 Sep 2005 00:59:30 +0200

=> no, the home agent can be a regular router too and route
packets for nodes which are not mobile clients.

=> we speak also about SPD entries on the home agent.   

=> hard-coding the MN's HoA in the SPD entries is just necessary:
the protection is required for and only for MNs which are clients
of the mobility service.

=> it is easy to parse and to check. Again it is for computers
which have a very different taste than humans.

=> of course, there is no post 2401bis document!

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 09 Sep 2005 01:09:18 +0200

=> can you put again the issue 33 in the list? I am afraid that
the decision is wrong.

Regards

PS: home agents can be regular routers too: the protection should be
required only for "interesting" packets from/to MNs which are clients
of the homw agent mobility service, and must not be required by packets
going through the router and which are by accident "interesting".
So it is critical the SPD is not underspecified, i.e., put an ANY
in place of a list of addresses and shoot randomly "innocent" packets
is not the right way.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 08 Sep 2005 16:20:37 -0700

> => can you put again the issue 33 in the list? I am afraid that

issue 33 was about whether the home address of the MN should be
used in scanning traffic for a HoTi message and then applying
the right protection.

I think the home address is not needed for the match. the MN
just needs to match the MH and MH type (HoTi), then it needs
to use a tunnel mode ESP SA. if there is none, create one
using home address as the inner src address, CoA as the outer
source address, HA's address as the outer destination address.

the home agent needs to have a similar SPD entry for any HoT
message it receives from the CNs. in this case, the HA needs
to look for MH and MH type (HoT). in particular this HoT
message should not have originated at the HA. it should have
come from a CN. once the match is done, the HA needs to use
a tunnel mode ESP SA. if there is none, it has create one,
with HA's own address as the outer source address and MN's
CoA as the outer destination address. when the HA picks its
own address it has to make sure the address it picks is the
same as the address the mobile node assumes to be the address
of the Home Agent. it shouldnt pick any other address from
any other interface on the HA.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Fri, 09 Sep 2005 01:51:32 +0200

=> so I can confirm the decision is wrong and the home address
must be used.

   If there is none, it has create one,
   with HA's own address as the outer source address and MN's
   CoA as the outer destination address.

=> for a packet which is "only" a HoTi there is no such things,
i.e., HA's own address and MN's CoA. They exist only for known
MNs and even for the CoA for registered MNs.

Thanks