Subject: Re: [nemo] Implemetor's comments on RFC3963

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 02 Nov 2005 18:39:22 -0800

Alexandru Petrescu wrote:
> Dear all,
> 
> Here are some remarks that came up while implementing RFC3963 MR and HA
> on laptops over iWiFi.
> 
> page 12, last par:
> 
>>   If the Binding Acknowledgement from the Home Agent has the status
>>   140, the Mobile Router SHOULD send a Binding Update to another Home
>>   Agent on the same home link.
> 
> 
> But how could the MR know another HA?  The only way to build the HA list
> is currently with DHAAD.  Per rfc3775 DHAAD is not mandatory to happen,
> and the bootstrapping procedure is not yet fixed.

RFC 3963 assumes DHAAD is used to obtain the list of HAs
that support mobile routers.

> In addition, even if the MR learns a list of HAs by some other means
> (like manual configuration), the MR should probably not send a BU to
> another HA which only supports MHs.

true. but if it uses DHAAD, then it knows whether the HA
supports mobile routers. otherwise, it would know when the
binding ack comes back without the 'R' flag.

> So I suggest to relax the SHOULD from above to a MAY, and probably later
> make it a MUST.  Additionally, I suggest to send the BU to another HA
> that supports Mobile Routers (not just any HA).

ok.

> page 14, 1st par:
> 
>>However, the Mobile
>>   Router SHOULD reply with Neighbor Advertisements to Neighbor
>>   Solicitations received on the egress interface, for addresses valid
>>   on the visited link.
> 
> 
> It was not immediately obvious what a "valid address on the visited
> link" is, terminology of "valid address on a link" is not yet widely
> used by the non-IETF.  So it would be good to shortly explain the "valid
> address".
> 
> For example, "for addresses derived from that link's prefix, that do not
> risk being ingress filtered by that link's router" or similar.

sounds good to me.

> 
> page 15, last bullet, and over to page 16:
> 
>>   -  If a Mobile Network Prefix Option is present in the Binding
>>      Update, the prefix information for the Mobile Network Prefix is
>>      retrieved from the Mobile Network Prefix field and the Prefix
>>      Length field of the option.  If the Binding Update contains more
>>      than one option, the Home Agent MUST set up forwarding for all the
>>      Mobile Network Prefixes.  If the Home Agent fails to set up
>>      forwarding to all the prefixes listed in the Binding Update, then 
>>      it MUST NOT forward traffic to any of the prefixes.  Furthermore,
>>      it MUST reject the Binding Update and send a Binding
>>      Acknowledgement with status set to 141 (Invalid Prefix).
>>
>>      If the Home Agent verifies the prefix information with the Prefix
>>      Table and the check fails, the Home Agent MUST discard the Binding
>>      Update and send a Binding Acknowledgement with status set to 142
>>      (Not Authorized for Prefix).
> 
> 
> Security-wise, the implementation order of verification would put the
> last par before the middle of the first par:  the HA first checks the
> MNP against the Prefix Table and only then it tries to set up forwarding.

agreed.

> The detail explanation of how the search in the Prefix Table could help
> too, especially since we count on the Prefix Table as a security measure.
> 
> -would HA check the HoA for every entry's HoA field and then match the
>  MNP in the BU against that entry's MNP field?
> -or would it first check the MNP and then the HoA?
> -what's a successfull check.

shouldnt this be implementation specific? its internal
to the HA.

> 
> page 16, 2nd bullet:
> 
>>  -  If there is no option in the Binding Update carrying prefix
>>      information, the Home Agent uses manual pre-configured information
>>      to determine the prefixes assigned to the Mobile Router and to set
>>      up forwarding for the Mobile Network.  If there is no information
>>      that the Home Agent can use, it MUST reject the Binding Update and
>>      send a Binding Acknowledgement with status set to 143 (Forwarding
>>      Setup failed).
> 
> 
> It was not immediately obvious what "manual pre-configured information"
> represents.  Maybe it would be clearer to just say "routing table"
> instead of explaining "manual pre-configured information".

well the prefix table could be used too. if you remember we
deliberatly picked this text. it is very possible that the
prefix information is stored somewhere else and routing
entries are only created when the BU is received. in such a
case the routing table wont be used.

> page 20, last par:
> 
>>  A new flag (R) (Support for Mobile Routers) is introduced in the
>>   DHAAD Reply message, defined in [1].  If a Home Agent receives a
>>   Dynamic Home Agent Discovery request message with the Mobile Router
>>   Support Flag set, it MUST reply with a list of Home Agents supporting
>>   Mobile Routers.  The Mobile Router Support Flag MUST be set if there
>>   is at least one Home Agent supporting Mobile Routers.  If none of the
>>   Home Agents support Mobile Routers, the Home Agent MAY reply with a
>>   list of Home Agents that only support Mobile IPv6 Mobile Nodes.  In
>>   this case, the Mobile Router Support Flag MUST be set to 0.
> 
> 
> Again on terminology of "Mobile Nodes".  What we want to achieve with
> the above par is that if there's no HA supporting MRs then the HA should
> reply with a list of HAs that only support Mobile Hosts.  So I suggest
> substitute Mobile Hosts for Mobile Nodes in the paragraph above.
> 
> (at several places throughout 3963 we made good distinction Mobile Host
> - Mobile Router and avoided "Mobile Node").

you are right. it should say mobile hosts.

> page 21, the message format:
> 
>>    0                   1                   2                   3
>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |     Type      |     Code      |            Checksum           |
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |           Identifier          |R|           Reserved          |
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>   |                                                               |
>>   +                                                               +
>>   +                                                               +
>>   |                                                               |
>>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> It would be convenient if that wide field after "Reserved" would have a
> textual description pasted on it, about its contents.  Otherwise and
> implementor has to dig it in rfc3775.

agreed. dont know how we (even the RFC Editor) missed this.

> That's all we have up to now, and all other preceding text was easily
> understood and we have it implemented and tested, we're happy with that.

awesome. :)

Vijay

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 4 Nov 2005 01:28:55 +0900

Hi Alex and Vijay

Please check interoperability with our implementation, SHISA:-)

some comments inline.

>> that supports Mobile Routers (not just any HA).

Only if there is another NEMO capable HA, it MUST send BU to the HA.
Otherwise, it re-issues DHAAD or stop sending BU.

>> risk being ingress filtered by that link's router" or similar.

Well, we should be very careful for the valid address definition.
If i remember correctly, the valid address's ND state must be  
preferred or deprecated.
NA must not be replied for an address which state is tentative and  
invalid.
We should check NDP spec...

>>>      forwarding to all the prefixes listed in the Binding Update,  
>>> then      it MUST NOT forward traffic to any of the prefixes.   
>>> Furthermore,

agree with Vijay.

thanks
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Nov 2005 17:51:19 -0800

Ryuji Wakikawa wrote:
>>> Dear all, Here are some remarks that came up while implementing 
>>> RFC3963 MR  and HA on laptops over iWiFi. page 12, last par:
>>> 
>>>> If the Binding Acknowledgement from the Home Agent has the 
>>>> status 140, the Mobile Router SHOULD send a Binding Update to 
>>>> another  Home Agent on the same home link.
>>> 
>>> But how could the MR know another HA?  The only way to build the 
>>> HA list is currently with DHAAD.  Per rfc3775 DHAAD is not 
>>> mandatory to  happen, and the bootstrapping procedure is not yet 
>>> fixed.
>> 
>> 
>> RFC 3963 assumes DHAAD is used to obtain the list of HAs that 
>> support mobile routers.
>> 
>>> In addition, even if the MR learns a list of HAs by some other 
>>> means (like manual configuration), the MR should probably not 
>>> send a BU to another HA which only supports MHs.
>> 
>> 
>> true. but if it uses DHAAD, then it knows whether the HA supports 
>> mobile routers. otherwise, it would know when the binding ack comes
>>  back without the 'R' flag.
>> 
>>> So I suggest to relax the SHOULD from above to a MAY, and 
>>> probably later make it a MUST.  Additionally, I suggest to send 
>>> the BU to another HA that supports Mobile Routers (not just any 
>>> HA).
>> 
>> 
>> ok.
> 
> 

Ok me too.  A clarification is still needed as suggested above I think.

>>> page 14, 1st par:
>>> 
>>>> However, the Mobile Router SHOULD reply with Neighbor 
>>>> Advertisements to Neighbor Solicitations received on the egress
>>>>  interface, for addresses  valid on the visited link.
>>> 
>>> It was not immediately obvious what a "valid address on the 
>>> visited link" is, terminology of "valid address on a link" is not
>>>  yet widely used by the non-IETF.  So it would be good to shortly
>>>  explain the "valid address". For example, "for addresses derived
>>>  from that link's prefix, that  do not risk being ingress
>>> filtered by that link's router" or similar.
>> 
>> 
>> sounds good to me.
> 
> 
> Well, we should be very careful for the valid address definition. If 
> i remember correctly, the valid address's ND state must be  preferred
>  or deprecated. NA must not be replied for an address which state is 
> tentative and invalid. We should check NDP spec...

Ok, if "valid address" could be formulated easily in ND-state terms I
agree with it.  It's just a simple issue, I don't look to make the
document much longer to explain what "valid address" is.  Just a short
explanation.

>>>>  Update, the prefix information for the Mobile Network Prefix
>>>> is retrieved from the Mobile Network Prefix field and the
>>>> Prefix Length field of the option.  If the Binding Update
>>>> contains more than one option, the Home Agent MUST set up
>>>> forwarding for all the Mobile Network Prefixes.  If the Home
>>>> Agent fails to set up forwarding to all the prefixes listed in
>>>> the Binding Update, then      it MUST NOT forward traffic to
>>>> any of the prefixes. Furthermore, it MUST reject the Binding
>>>> Update and send a Binding Acknowledgement with status set to
>>>> 141 (Invalid Prefix).
>>>> 
>>>> If the Home Agent verifies the prefix information with the 
>>>> Prefix Table and the check fails, the Home Agent MUST discard 
>>>> the Binding Update and send a Binding Acknowledgement with 
>>>> status set to  142 (Not Authorized for Prefix).
>>> 
>>> Security-wise, the implementation order of verification would put
>>>  the last par before the middle of the first par:  the HA first 
>>> checks the MNP against the Prefix Table and only then it tries to
>>>  set up forwarding.
>> 
>> 
>> agreed.
>> 
>>> The detail explanation of how the search in the Prefix Table 
>>> could  help too, especially since we count on the Prefix Table as
>>>  a security measure. -would HA check the HoA for every entry's
>>> HoA field and then match  the MNP in the BU against that entry's
>>> MNP field? -or would it first check the MNP and then the HoA?
>> shouldnt this be implementation specific? its internal to the HA.
> 
> 
> agree with Vijay.

It is indeed implementation-specific.  It should however clarify _why_
this check is done and the kind of attack it protects against.  The text
 could say: "this Prefix Table verification helps protect against an
attack where an attacker MR sends BUs with the legitimate MR's MNP, both
MRs being managed by same HA".

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 07 Nov 2005 18:13:46 -0800

> MRs being managed by same HA".

we have some text in section 6.1.2

    The Home Agent SHOULD be able to prevent a Mobile Router from
    claiming Mobile Network Prefixes belonging to another Mobile Router.
    The Home Agent can prevent such attacks if it maintains a Prefix
    Table and verifies the prefix information provided by the Mobile
    Router against Prefix Table entries.

isnt this sufficient?

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 07 Nov 2005 18:20:31 -0800

Vijay Devarapalli wrote:

>>>>> could help too, especially since we count on the Prefix Table
>>>>> as a security measure. -would HA check the HoA for every
>>>>> entry's HoA field and then match  the MNP in the BU against
>>>>> that entry's MNP field? -or would it first check the MNP and
>>>>> then the HoA? -what's a successfull check.
>>>> 
>>>> 
>>>> 
>> It is indeed implementation-specific.  It should however clarify
>> _why_ this check is done and the kind of attack it protects
>> against.  The text could say: "this Prefix Table verification helps
>> protect against an attack where an attacker MR sends BUs with the
>> legitimate MR's MNP, both MRs being managed by same HA".
> 
> 

Sorry - I agree!  For some reason that text wasn't immediately handy to
me.  That was exactly the text I was looking for.

If both of you guys think that that text is enough, and that an example
check is not necessary (check the MNP of BU to MNP in the prefix table,
exact match with prefix length) then I won't fight for it.

Alex

---

From: Simon Oosthoek <[email-masked]>
Date: Tue, 08 Nov 2005 09:13:58 +0100

> exact match with prefix length) then I won't fight for it.

Just out of interest, how would you verify this table? I'm sure this 
would need some form of crypto verification to make sure the MR isn't an 
imposter, right?

(I'm looking at NEMO as a solution for secure personal networks, so from 
my perspective, authentication and authorisation is very important)

Cheers

Simon
-- 
phone:(+31|0)53 4810319
fax:  (+31|0)53 4810333
[email-masked]
http://www.ti-wmc.nl/

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 08 Nov 2005 09:38:00 -0800

> would need some form of crypto verification to make sure the MR isn't an 

do you want to authenticate the mobile router or check
if the mobile router is authorized to use a certain MNP?

if its the former, the MR and the HA run IKEv2 to
authenticate each other and setup security associations.
if its the later, the prefix table contains a mapping
of the identity of the mobile router to the MNPs that
it is allowed to advertise on the mobile network.

Vijay