Re: [shim6] Unknown locator [WG Last Call for draft-ietf-shim6-multihome-shim-api]

[Shinta Sugimoto <[e-mail]>]

Hi,

I am sorry for the delay in resonse. Let me address my view on the unknown locator issue.

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]] 
> Sent: Monday, December 14, 2009 8:52 PM
> To: Shinta Sugimoto
> Cc: [e-mail]; Kristian Slavov; [e-mail]
> Subject: Unknown locator [WG Last Call for 
> draft-ietf-shim6-multihome-shim-api]
> 
> On 2009-12-14 17:23, Shinta Sugimoto wrote:
> ...
> >>> 14.  Security Considerations
> >> It seems to me that the Unknown Locator mechanism described in 
> >> section 11.4 might act as a bypass for the security 
> mechanism applied 
> >> by the shim.
> > 
> > Let me clarify if I undertand your comment.
> > Yes, application may provide locator(s) which the multihome shim 
> > sub-layer may not be aware of.  In principle, the reaction of the 
> > multihome shim sub-layer must be aligned with what is stated in 
> > Section 7.2 (Locator Verification) of RFC 5533.  Besides, I 
> think an 
> > error message must be returned to the application when it 
> tries to use unknown locator as the source address for 
> outbound user traffic.
> > Does this cover your concern?
> 
> Well, I don't quite understand how an extra locator provided 
> by the upper layer can ever pass the CGA/HBA test. So I don't 
> really understand the unknown locator mechanism, I guess. 
> Maybe it can never work in the case of SHIM6 or HIP but might 
> work with some other kind of shim?

After re-thinking, I think we need to handle two cases: 1) application sending data with unknown source/destination locator, 2) application requesting for using unknown source/destination locator.

As to the former case, the multihoming shim sub-layer must reject the request and send an error message to the application.  The reason is simply because the packet with unknown source locator will be dropped by the peer and sending packet to unknown destination locator should be prohibited for security reasons.

As to the latter case, the multihoming shim sub-layer should do the following:

In response to the request for using unknown source locator:

- check if the requested source locator is available on any of the local interface
- if the source locator is available, then the multihoming shim sub-layer MAY initiate procedure to update its own locator list with the peer

In response to the request for using unknown destination locator, the situation is a bit tricky because it means that the application somehow knows another locator (IP address) to reach the peer while the multihoming shim sub-layer does not.  I am not sure if we have such a case in reality, but in theory, I think the multihoming shim sub-layer must reject the request at least in the case of SHIM6.  In the case of HIP, I am clarifying this with HIP experts what to do.

Any comments?

p.s., Please note that I will be off-line for 1.5 days from now due to business travel.  Will be able to response on 19 December.

Regards,
Shinta