Subject: Re: [mobile-ip] Re: MIPv6 Draft 18 Comments

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 20 Aug 2002 19:02:07 -0700 (PDT)

Hi Jari,

Thanks for your response. The discussion points are in-line.

> > 3.
> > section 6.1.8 indicates that we don't have "no Security
> > Association" status code anymore and we have:
> > 
> > 137   Invalid authenticator
> > 
> > That suggests Binding Authorization Data Option is manadatory
> > for all binding update messages--correct ?
> 
> Not quite. BAD (!) options are mandatory for CN binding updates,
> but not for HA binding updates.
>

Ok. So the HA binding update can have IPsec transport mode alternatively.
 
> > If that is the case, then that must be specified in 6.1.7
> > as well. Otherwise, we need another status error code or
> > specification when the HA or CN receives a BU without
> > binding authorization data option.
> 
> My suggestion is to rename 137 as "Invalid or missing authenticator",
> which would cover the case where BAD wasn't included in a BU to a
> CN.
> 

Ok. Then this is valid for CN case, but not for HA case. How should HA
react if it receives a BU without BAD or IPsec (or any other security
mechanism in future) ?  

Do you think "No security association" error code would be valid for
this case ?

> > 4.
> > 
> > 6.1.9
> > 
> > Status code 1:
> > 1   Home Address destination option used without a binding
> > Is this still valid ?
> 
> I think it is still valid, but a more proper name would perhaps
> be "Home Address destination option used without sufficient validation",
> the validation mechanisms being (1) existing binding or (2) use of
> IPSec.
> 
Ok.

> Note that this issue is separate from the discussion of whether or
> not the HAO and the IPsec validation are mandatory. (Whether or not
> they are, it is still possible that someone sends an unauthenticated
> HAO without a binding.)
> 

So the code should check in the following order:

1) If IPsec association is present
2) If there is an existing binding
3) If this is a mobility header type for binding update

If none of those conditions satisfy, then the above error status
code should be sent-right ?

> > 5.
> > section 8.2 Route Optimization Requirements for All IPv6 Nodes
> > 
> > It's missing the MN behavior,
> > 
> > How about adding a text something like this?
> > 
> > A node that is performing mobile node operation MUST be able to
> > process RTHDR_TYPE2 extension header (section 11.2.3 and 6.4).
> > All other nodes MUST ignore and drop RTHDR_TYPE2 extensions.
> 
> Hmm... ok, but the purpose of this section was to list only requirements
> for CNs. A CN can also be an MN at the same time. How about
> 
>     Unless the correspondent node is also acting as a mobile node,
>     it MUST ignore Type 2 Routing headers and drop all packets
>     that it has received with such headers.
> 

Fine w/me.

> We should also change:
> 
>     The following requirements apply to all nodes that support route
>     optimization:
> 
> to
> 
>     The following requirements apply to all correspondent nodes that support 
route
>     optimization:
> 
> I'll put this under issue #101.
>

Ok. 

> > section 8.5
> > 
> > Additional requirement:
> > 
> > -MUST be able to process RTHDR_TYPE2 extension header as defined
> >  in 6.4 and 11.2.3
> 
> Yes. "RTHDR_TYPE2 extension header" => "Type 2 Routing header"
> 

Right. Sorry about the mix-up.

> > 11.
> > section 10. Home Agent Operation
> > 
> > Should not we have a section here on "Processing Binding Updates" ?
> 
> Isn't 10.2 & 10.3 just that? Or would you like a different name?

You are right. For consistency with CN and MN, how about naming this 
section accordingly ?

Also, there has been requests in the alias to clarify the security mechanism
and processing associated with BU processing at home agent. 

Thanks again,
-Samita

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 21 Aug 2002 09:27:08 -0400

> Do you think "No security association" error code would be valid for

Why not just name error code 137 as "Authentication Failed" and return
that error code if the security validation procedure (IPSec, BAD, etc...)
failed.

-vlad
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich	       Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 	       Tel: (603) 884-1079
Nashua, NH 03062	       ZKO3-3/T07

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Aug 2002 16:40:07 +0300

> that error code if the security validation procedure (IPSec, BAD, etc...)

IPsec has its own mechanisms (i.e. drop packets and not tell anyone about
it) for dealing with authentication problems. So that's why I'm a bit
hesitant to require that the MIPv6 code needs to know too much about what
happened lower down in the stack.

Jari

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 21 Aug 2002 09:47:01 -0400

Jari

I agree, if IPSec actuall failed, that packet will be just dropped at
lower layer, but a different error code description is still valid
for when there was not authentication done on the packet.

The new description is also generic enough to cover possible future
authentication mechanisms other then BAD and IPSec.

-vlad

Jari Arkko wrote:
>>> mechanism in future) ? Do you think "No security association" error 
>>> code would be valid for
>>> this case ?
>>>
>>

--

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 26 Aug 2002 12:47:58 -0700

> react if it receives a BU without BAD or IPsec (or any other security

I prefer just dropping the BU. there is no need for the HA to send
a BA with yet another error status.

Vijay