Subject: [Mipshop] review of draft-faccin-mih-infoserv-01.txt

From: Jari Arkko <[email-masked]>
Date: Fri, 13 Jan 2006 18:52:07 +0200

I reviewed this draft too, though very quickly. Here are some
comments anyway:

Overall:

There's a lot more detail in this draft than in the other
one that I looked at. That's good.

Technical:

>    The exact SA negotiation mechanism described depends on the transport
>    layer used, and security services required.  For example, TLS may be
>    applicable if upper layer protocols use TCP, while ESP using IPSec/
>    IKE will work in most situations, regardless of the upper layer
>    protocol, so long as the IS protocol identifiers are handled by IKE
>    [5][6][7].

While this is true, there are also other aspects in the selection
of suitable underlying security mechanism. For instance, TLS
is significantly easier to integrate to per-application policies.

>    o  Distinguish between the packet source and query source (allow
>       proxies).

The security mechanism discussions in the draft do not
take this into account.

>    o  Provide compatability with Address or Security Association
>       Mobility management, to allow use of an IS server after host
>       movements without renegotiating an SA.

But this seems to solve only a part of the problem, as it
is also possible that you move to a different network and
consequently need to use a different server, too. An approach
that would work well for both is making the session set
up fast. Not sure if that is achievable, though. But I would
not take it for granted that we need to use session-based
security mechanisms underneath. Presumably some of the
information over MIH is fairly static, so you could also sign
the data objects.

Editorial:

>    network discovery is important for compatability, though, so it may

typo

>    o  Optionally ensure compatability between the information services
>       transport, and those required for Event and Command Services.

and here

>    If the mobile's address changes, it may be possible to reuse an
>    existing SA by updating the addresses to use for communication
>    endpoint addresses using Mobile IPv6 Route Optimization, or IKEv2
>    session mobility [19][23]. 

The second reference should probably be to draft-ietf-mobike-protocol,
not -design. And the text could be changed to ... or MOBIKE.

--Jari

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

---

From: Greg Daley <[email-masked]>
Date: Sat, 14 Jan 2006 13:38:04 +1100

Hi Jari,

Thanks for looking at this.

> is significantly easier to integrate to per-application policies.

Yes. I think we weren't looking too closely in that case as we
didn't want to get too far ahead of ourselves.

We'll have a think about this issue and will probably make
use of your input in this case.

> The security mechanism discussions in the draft do not

Yes. I think we need to update the discussion.

> information over MIH is fairly static, so you could also sign

That makes sense, as it matches the previous issue (which needs
elaboration for data origin authentication).

the issue of fast SA setup (whatever it actually means) should be
added here as a requirement or nice-to-have.  You're right in
that it would help to solve things more neatly.

>>       transport, and those required for Event and Command Services.

I'll run ispell over the next draft revision... sorry.

> not -design. And the text could be changed to ... or MOBIKE.

OK.  Sorry, I've not been following the WG all that recently.

(back to my thesis...)

Greg

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 21 Jan 2006 12:54:16 +0200

Hello,

I just finished reading the I-D draft-faccin-mih-infoserv-01.txt.

   This document provides a view of the authors, and doesn't represent
   the official view of either IEEE 802.21 or an IETF WG.  Assistance is
   sought to improve this document, in order to reflect consensus
   viewpoints from the appropriate groups.

   ...

   This draft provides an incomplete description of the 802.21's
   progress, and people are encouraged to read the 802.21 draft
   themselves [1].

   ...

   At this stage, significant feedback is required from both MIPSHOP
   working group and 802.21 Task Group, to confirm the validity of the
   scenarios from Section 3, and develop the descriptions in the
   subsections below.

Given that IS is a concept designed by the IEEE, and IEEE is the one
requesting IETF to come up with an "IS" protocol, I was naturally expecting
to see a requirements document produced by IEEE. 

I think the requirements document should be discussed in IEEE and finalized
there, and fed into the IETF. We can have an informative discussion here,
but the authoritative discussion forum is the IEEE. 

Also, I think this I-D goes a bit beyond requirements. Somewhat it is
influenced by a specific or conceptual design (e.g., call flow in 4.2,
hop-by-hop nature defined in Figure 6), and it even analyzes various
alternatives. I think the final requirements should not have these.

Alper