Subject: RE: [Mipshop] .21 MIH solutions

From: "Hepworth, Eleanor" <[email-masked]>
Date: Thu, 6 Jul 2006 17:15:53 +0100

Hi Alper

Some comments below:

> Going back to our draft-jang-mipshop-nhdisc-00.txt 
> presentation, there were few issues brought up. We didn't 
> have enough time for detailed discussion on those during the 
> meeting. It'd be useful to take a look at them.
> 
> - Security association end-points:
> 
> It was brought up that the proxy model requires an SA between 
> the proxy and the IS. That's true. Either that, or an SA 
> between the host and the IS is required if we go with the 
> direct model. IMO, given that the IS may be a remote server 
> (right?), the latter is harder to realize.

Agreed - in the design considerations draft we've assumed that security
is only needed between adjacent MIH peers, which I think matches what
you're saying here.
 
> - Privacy:
> 
> Direct model where the information elements are end-to-end 
> encrypted obviously achieve greater privacy. But going back 
> to the previous point, it is a lot harder to achieve. And we 
> need to consider the value of keeping the information 
> elements private in the face of this cost. 

Also agreed.  It certainly seems that end-to-end privacy is needed for
particular Information Elements, this is going to get very specific to
the application itself.  It would then seem better to push this problem
back into the MIH application solution (cf. what was done/not done with
Diameter regarding the use of CMS).
 
> - One vs. multiple protocols for CS, ES, and IS:
> 
> On the surface using a single protocol is better than using 
> separate protocols. But the nature of CS and ES appears to be 
> more L2 dependant. For that, realizing CS and ES over L2 
> whereas IS over L3 is a plausible solution. Well, at least we 
> shall not get carried away at IETF since we think we can do 
> everything at or above L3 :-)

One point is that we need to be clear that L3 support for ES/CS is in
any case required as there may be link layers that can't be extended to
support them, and there are also scenarios where these services
(especially CS) may be deployed deeper in the network (for example, an
operator core network).

In general, whether one or several protocols get defined, we think it's
highly desirable that the protocol(s) get designed in a co-ordinated way
so the complete set of MIH applications see a common network environment
(e.g. in terms of used identifier spaces, discovery process,
security/threat analysis etc.).  Whether the end result is one
configurable protocol or three separate protocols under a common API is
to some extent a secondary issue.

Thanks

Ele
> 
> Comments welcome.
> 
> Alper
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 

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

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 6 Jul 2006 12:48:41 -0700

Hi Eleanor,

> (especially CS) may be deployed deeper in the network (for example, an

The latter sounds like a theoretical possibility, but is it really
practical? I mean, I'd rather expect the core network to issue the command
to an access network device (NAS, or BS), and than in turn that device
issuing the command to the mobile host. When it comes to causing L2 events
(e.g., disconnect, re-auth, etc.), I think the current architectures are
modeled that way.

> to some extent a secondary issue.

I agree.

Alper