Subject: [MIPSHOP-MIH-DT] Work items breakdown

From: Telemaco Melia <[email-masked]>
Date: Wed, 06 Jun 2007 18:33:59 +0200

Dear all,

Here it goes my proposal.
After the presentation Robert did last meeting we agreed to the 
following main three areas:
- The layer split (MSTP)
- Node discovery and message routing
- Security and resilience

I would keep the same working areas and explore sub items as follow.

About MSTP the following issues were identified:
- identifiers of MSTP users (related to the 802.21 MIHFID)
- implication of the discovery mechanisms
- attributes of the message transfer
Additionally in the PS doc the following requirements are related to 
attributes configuration:
- low latency
- reliability
- congestion control
- multiplexing
- multihoming
- v6/v4 support (including NAT/firewall traversal)

About Node discovery and message routing we need to identify scenarios 
(the PS just says what are the properties).
We did not discuss about this yet and I believe this is the most 
critical part of the whole problem.

About security the PS identifies:
- information from a trusted source
- security association management
- secure delivery

Would the breakdown help in solving the problems?
Let's fix this and then discuss assignments.

Let me know asap.
telemaco

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Sam Xia <[email-masked]>
Date: Thu, 07 Jun 2007 14:12:20 +0800

Best Regards, Sam Xia 

> -----Original Message-----
> From: Telemaco Melia [mailto:[email-masked]] 
> Sent: Thursday, June 07, 2007 12:34 AM
> To: [email-masked]
> Subject: [MIPSHOP-MIH-DT] Work items breakdown
> 
> Dear all,
> 
> After the presentation Robert did last meeting we agreed to 
> the following main three areas:
> - The layer split (MSTP)
> Additionally in the PS doc the following requirements are 
> related to attributes configuration:
> - low latency
> - reliability
> - congestion control
> - multiplexing
> - multihoming
> About Node discovery and message routing we need to identify 
> scenarios (the PS just says what are the properties).
> We did not discuss about this yet and I believe this is the 
> most critical part of the whole problem.
>

---

From: Sam Xia <[email-masked]>
Date: Thu, 07 Jun 2007 15:21:50 +0800

Hi Tele, all,
 Thank you for your input.
I think that it is very good that we should have consensus on the designing
principle (about discovering, transportation, security)before discussing the
assignment.  So, I have some comments on the input from Tele. I wish that
everyone can reply actively.
please see the inline.

> - Node discovery and message routing

Until now, we have no rough consensus on the discovering issue. The
followings are my questions that are worthy of discussing, as well as my
comments.

a) Should we resort to the existing the protocols and states, such as DHCP?
I think that DHCP is a very good candidate for MIHF discovering mechanism.
But, in [design-consideration], it is mentioned that DHCP is a possible
candidate, but only be the most suitable for link technologies where this is
used as an address assginment method. My suggenstion is that we can use DHCP
as a mandatory discovering mechanism though DHCP is not used to assign
address.

b) if we aggree to design a new discovering mechanims, what should it look
like?
If the discovering mechanism looks like the DHCP and the solution is
deployed only in the access networks, not deep into the core network or
remote network,  why do we have to design this solution instead of DHCP?
If the discovering mechanism looks like the GIST and can be deployed from
the access network to core network (a lot of routers are required to
implement it), can we take so much expense only for discovering service?
Even the GIST-alike solution can be deployed only in the access network, do
we have any other reasons to adopt so complicated discoverying mechanism?

> - v6/v4 support (including NAT/firewall traversal)

Before we discuss the above items, i think we should consider the following
questions:

What is the base protocol for MIHF transportation? Is it TCP/UDP/SCTP/raw
socket, or the compound of them?

Can we use different transportation protocol in order to meeting with the
different attributes just as GIST does?

> - security association management

Before we discuss the above the security issues, it is worthy of discussing
the following:

What is our choice between TLS and IPSec, or something else?

I am sure that the security protocol can solve the authentication
issue(information from a trusted source).

As to the SA manangement, I think that we have to spend much time on this
point. As we all know, there are  a lot of SAs between MN and the network
entity in the network side, such as the SA between MN and Home Agent, the SA
between MN and AAA/authenticator/AP(discussed in HOKEY). My question is that
whether we should create a new SA between MIHFs in MN and in network entity,
independent of the said-above SAs or correlated with them?

If we use security protocol, I don't think secure delivery is a problem.

---

From: "Stefano Faccin" <[email-masked]>
Date: Thu, 7 Jun 2007 07:53:59 -0700

Hello all,
I have a couple of comments. 

I am not sure that making any specific discovery mechanism mandatory
would be a safe constraint. I would suggest that as result of the DT we
provide a recommended mechanism for discovery of MIHF. However, if we
want the result of the DT to be used by other fora, we need to make sure
that other solutions are possible (e.g. for a specific link layer the
MIHF address may be provided to the terminal through link-layer specific
mechanisms). There should be a clause in the DT design document that
indicates other mechanisms are possible, and that a given one is
recommended.

As for the establishment of SAs, I think it is safer to assume that the
MIHF is functionally separate from other network entities. In fact, we
have no control on how MIH will be deployed in other fora, and therefore
in order to allow the MIH solution to be applied to various
configurations/architectures, we need to provide flexibility. Therefore,
the basic solution should consider two cases:
- SAs established between the MN and the MIHF separately from any other
SAs the MN may already have
-  no SA establishment (i.e. to cater for the case where the specific
architecture where MIH is deployed implements the MIHF in a logical
network node that already has an SA with the MN that can be re-used),
i.e. do not make the SA establishment mandatory
Scenarios where optimizations are introduced to address the cases Sam
identifies can be considered in a later phase, perhaps?
Cheers,
Stefano

Hi Tele, all,
 Thank you for your input.
I think that it is very good that we should have consensus on the
designing
principle (about discovering, transportation, security)before discussing
the
assignment.  So, I have some comments on the input from Tele. I wish
that
everyone can reply actively.
please see the inline.

a) Should we resort to the existing the protocols and states, such as
DHCP?
I think that DHCP is a very good candidate for MIHF discovering
mechanism.
But, in [design-consideration], it is mentioned that DHCP is a possible
candidate, but only be the most suitable for link technologies where
this is
used as an address assginment method. My suggenstion is that we can use
DHCP
as a mandatory discovering mechanism though DHCP is not used to assign
address.

b) if we aggree to design a new discovering mechanims, what should it
look
like?
If the discovering mechanism looks like the DHCP and the solution is
deployed only in the access networks, not deep into the core network or
remote network,  why do we have to design this solution instead of DHCP?
If the discovering mechanism looks like the GIST and can be deployed
from
the access network to core network (a lot of routers are required to
implement it), can we take so much expense only for discovering service?
Even the GIST-alike solution can be deployed only in the access network,
do
we have any other reasons to adopt so complicated discoverying
mechanism?

> - v6/v4 support (including NAT/firewall traversal)

Before we discuss the above items, i think we should consider the
following
questions:

What is the base protocol for MIHF transportation? Is it
TCP/UDP/SCTP/raw
socket, or the compound of them?

Can we use different transportation protocol in order to meeting with
the
different attributes just as GIST does?

> - security association management

Before we discuss the above the security issues, it is worthy of
discussing
the following:

As to the SA manangement, I think that we have to spend much time on
this
point. As we all know, there are  a lot of SAs between MN and the
network
entity in the network side, such as the SA between MN and Home Agent,
the SA
between MN and AAA/authenticator/AP(discussed in HOKEY). My question is
that
whether we should create a new SA between MIHFs in MN and in network
entity,
independent of the said-above SAs or correlated with them?

---

From: Sam Xia <[email-masked]>
Date: Fri, 08 Jun 2007 14:42:56 +0800

Hi all,
 see the inline,

 Best Regards, Sam Xia 

> I am not sure that making any specific discovery mechanism 
> mandatory would be a safe constraint. I would suggest that as 
> result of the DT we provide a recommended mechanism for 
> discovery of MIHF. However, if we want the result of the DT 
> to be used by other fora, we need to make sure that other 
> solutions are possible (e.g. for a specific link layer the 
> MIHF address may be provided to the terminal through 
> link-layer specific mechanisms). There should be a clause in 
> the DT design document that indicates other mechanisms are 
> possible, and that a given one is recommended.

I am fine with this.

> 
> As for the establishment of SAs, I think it is safer to 
> assume that the MIHF is functionally separate from other 
> network entities. In fact, we have no control on how MIH will 
> be deployed in other fora, and therefore in order to allow 
> the MIH solution to be applied to various 
> configurations/architectures, we need to provide flexibility. 
> Therefore, the basic solution should consider two cases:
> - SAs established between the MN and the MIHF separately from 
> any other SAs the MN may already have
> -  no SA establishment (i.e. to cater for the case where the 
> specific architecture where MIH is deployed implements the 
> MIHF in a logical network node that already has an SA with 
> the MN that can be re-used), i.e. do not make the SA 
> establishment mandatory Scenarios where optimizations are 
> introduced to address the cases Sam identifies can be 
> considered in a later phase, perhaps?

I think so.

Tele, Robert and other teamates,  how do you think about Stefano's and my
comments?

> I think that it is very good that we should have consensus on 
> the designing principle (about discovering, transportation, 
> security)before discussing the assignment.  So, I have some 
> comments on the input from Tele. I wish that everyone can 
> reply actively.
> please see the inline.
> 
> 
> > 
> > Dear all,
> > 
> Until now, we have no rough consensus on the discovering 
> issue. The followings are my questions that are worthy of 
> discussing, as well as my comments.
> 
> But, in [design-consideration], it is mentioned that DHCP is 
> a possible candidate, but only be the most suitable for link 
> technologies where this is used as an address assginment 
> method. My suggenstion is that we can use DHCP as a mandatory 
> discovering mechanism though DHCP is not used to assign address.
> 
> b) if we aggree to design a new discovering mechanims, what 
> should it look like?
> If the discovering mechanism looks like the DHCP and the 
> solution is deployed only in the access networks, not deep 
> into the core network or remote network,  why do we have to 
> design this solution instead of DHCP?
> If the discovering mechanism looks like the GIST and can be 
> deployed from the access network to core network (a lot of 
> routers are required to implement it), can we take so much 
> expense only for discovering service?
> Even the GIST-alike solution can be deployed only in the 
> access network, do we have any other reasons to adopt so 
> complicated discoverying mechanism?
> 
> TCP/UDP/SCTP/raw socket, or the compound of them?
> 
> Can we use different transportation protocol in order to 
> meeting with the different attributes just as GIST does?
> 
> > 
> Before we discuss the above the security issues, it is worthy 
> of discussing the following:
> 
> I am sure that the security protocol can solve the 
> authentication issue(information from a trusted source).
> 
> As to the SA manangement, I think that we have to spend much 
> time on this point. As we all know, there are  a lot of SAs 
> between MN and the network entity in the network side, such 
> as the SA between MN and Home Agent, the SA between MN and 
> AAA/authenticator/AP(discussed in HOKEY). My question is that 
> whether we should create a new SA between MIHFs in MN and in 
> network entity, independent of the said-above SAs or 
> correlated with them?
>

---

From: <[email-masked]>
Date: Fri, 8 Jun 2007 17:30:27 -0500

Hi Sam,

>But, in [design-consideration], it is mentioned that DHCP is a 
>possible candidate, but only be the most suitable for link 

It is not entirely clear that DHCP would work for discovering
your home network when in a visited network.  Probably something
like RADIUS/Diameter could be used with a NAI to get you back
to your home network.  DHCP does not support roaming very well.
For example, if your DHCP server is in your home router, how
will it know where your home (cellular) MIHF is located?

My best guess is whatever mechanism is used, something like a NAI
is needed when you are outside of your home network.

John

---

From: <[email-masked]>
Date: Fri, 8 Jun 2007 17:32:34 -0500

>between MN and the network entity in the network side, such as 
>the SA between MN and Home Agent, the SA between MN and 

It still is a problem, if the security isn't end-to-end.  If the
security is hop-by-hop, each intermediary can potentially 
do something to the message payload if we don't deploy SMIME or
CMS. However, what is the security requirement here?

John

---

From: <[email-masked]>
Date: Fri, 8 Jun 2007 17:36:09 -0500

Telemaco,

The topics below look like a ToC (nearly).  Shall we just jump into
constructing a document, and assign pieces of it to DT members?

I would suggest that you create a ToC and we start filling it
out, and if some places are still under discussion, we capture
the discussion in the draft and continue the discussions on the WG
mailing list.

John 

>From: ext Telemaco Melia [mailto:[email-masked]] 
>Sent: 06 June, 2007 09:34

---

From: Sam Xia <[email-masked]>
Date: Mon, 11 Jun 2007 14:38:17 +0800

hi John,

> your home network when in a visited network.  Probably 
> something like RADIUS/Diameter could be used with a NAI to 
> get you back to your home network.  DHCP does not support 
> roaming very well.
> My best guess is whatever mechanism is used, something like a 
> NAI is needed when you are outside of your home network.
> 
 
What you said that DHCP is not suitable for discovering and locating the
home network. Right?   Yes, i aggree wiht you. 
But what we are talking about is how to discovering the MIHF entities in the
network.  Of cource, maybe the mobile node will use the MIH services
provided by the MIHF entities deployed in the home network.  How to
discovery the MIHF entities in the home network is a big problem when the
mobile node is roaming. Whether to use NAI is dependent on the specific
method. Do you think so?

BTW,  I don't know how and why the MIHF enitity in home network can collect
the IS elements from the visited network.

---

From: Telemaco Melia <[email-masked]>
Date: Mon, 11 Jun 2007 14:15:53 +0200

Hi John,

Here it goes. I started to associate names to sections based on recent 
discussions but I would like to know your opinion.
As for the discovery thread I am drawing a couple of pictures to capture 
the options described so far.

Views?
tele

>> Let's fix this and then discuss assignments.

Mipshop WG                                                    R. Hancock
Internet-Draft                                       Siemens Roque Manor
Intended status: Standards Track                           T. Melia, Ed.
Expires: December 13, 2007                                           NEC
                                                                  S. Xia
                                                                  Huawei
                                                             J. Loughney
                                                                   Nokia
                                                                 H. Jang
                                                                 Samsung
                                                                  S. Das
                                                               Telcordia
                                                           S. Sreematula
                                                                   Nokia
                                                              JC. Zuniga
                                                            Interdigital
                                                           June 11, 2007

              Mobility Services Transport Protocol Design
                   draft-xxx-mipshop-mstp-solution-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 13, 2007.

Copyright Notice

Hancock, et al.         Expires December 13, 2007               [Page 1]

Internet-Draft                    MSTP                         June 2007

   Copyright (C) The IETF Trust (2007).

Abstract

   To be edited.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Node Discovery and message routing  . . . . . . . . . . . . . . 3
     3.1.  Supported Scenarios . . . . . . . . . . . . . . . . . . . . 3
     3.2.  Implications on the MSTP  . . . . . . . . . . . . . . . . . 3
   4.  The layer split . . . . . . . . . . . . . . . . . . . . . . . . 3
     4.1.  Identifiers of MSTP users . . . . . . . . . . . . . . . . . 3
     4.2.  Attributes of the message transfer  . . . . . . . . . . . . 3
       4.2.1.  Low latency . . . . . . . . . . . . . . . . . . . . . . 3
       4.2.2.  Reliability . . . . . . . . . . . . . . . . . . . . . . 3
       4.2.3.  Congestion control  . . . . . . . . . . . . . . . . . . 3
       4.2.4.  Multiplexing  . . . . . . . . . . . . . . . . . . . . . 3
       4.2.5.  Multihoming . . . . . . . . . . . . . . . . . . . . . . 3
       4.2.6.  v4/v6 support . . . . . . . . . . . . . . . . . . . . . 3
   5.  Security and Resilience . . . . . . . . . . . . . . . . . . . . 3
     5.1.  Information from a trusted source . . . . . . . . . . . . . 3
     5.2.  Security association management . . . . . . . . . . . . . . 4
     5.3.  Secure delivery . . . . . . . . . . . . . . . . . . . . . . 4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 4
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7

Hancock, et al.         Expires December 13, 2007               [Page 2]

Internet-Draft                    MSTP                         June 2007

1.  Introduction

   Introduce the document, its structure and scope of the solution.

2.  Solution Overview

3.  Node Discovery and message routing

   Tele, John

3.1.  Supported Scenarios

3.2.  Implications on the MSTP

4.  The layer split

   Subir, JC

4.1.  Identifiers of MSTP users

4.2.  Attributes of the message transfer

4.2.1.  Low latency

4.2.2.  Reliability

4.2.3.  Congestion control

4.2.4.  Multiplexing

4.2.5.  Multihoming

4.2.6.  v4/v6 support

5.  Security and Resilience

   Sam, other volunteers?

5.1.  Information from a trusted source

Hancock, et al.         Expires December 13, 2007               [Page 3]

Internet-Draft                    MSTP                         June 2007

5.2.  Security association management

5.3.  Secure delivery

6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

7.  Security Considerations

8.  Acknowledgements

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses

   Robert Hancock
   Siemens Roque Manor

   Phone:
   Fax:
   Email:
   URI:

   Telemaco Melia (editor)
   NEC

   Phone:
   Fax:
   Email:
   URI:

Hancock, et al.         Expires December 13, 2007               [Page 4]

Internet-Draft                    MSTP                         June 2007

   Sam Xia
   Huawei

   Phone:
   Fax:
   Email:
   URI:

   John Loughney
   Nokia

   Phone:
   Fax:
   Email:
   URI:

   Heejin Jang
   Samsung

   Phone:
   Fax:
   Email:
   URI:

   Subir Das
   Telcordia

   Phone:
   Fax:
   Email:
   URI:

Hancock, et al.         Expires December 13, 2007               [Page 5]

Internet-Draft                    MSTP                         June 2007

   Srinivas Sreematula
   Nokia

   Phone:
   Fax:
   Email:
   URI:

   Juan Carlos Zuniga
   Interdigital

   Phone:
   Fax:
   Email:
   URI:

Hancock, et al.         Expires December 13, 2007               [Page 6]

Internet-Draft                    MSTP                         June 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Hancock, et al.         Expires December 13, 2007               [Page 7]

---

From: Sam Xia <[email-masked]>
Date: Tue, 12 Jun 2007 17:03:13 +0800

Who is/are interested in section 2 (solution overview)? we have to come up
with the solution overview first, then we can do independently.

 Best Regards, Sam Xia 

> Sent: Monday, June 11, 2007 8:16 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [MIPSHOP-MIH-DT] Work items breakdown
> 
> Hi John,
> 
> Here it goes. I started to associate names to sections based 
> on recent discussions but I would like to know your opinion.
> As for the discovery thread I am drawing a couple of pictures 
> to capture the options described so far.
> 
> Views?
> tele
> 
> 
> > I would suggest that you create a ToC and we start filling 
> it out, and 
> > if some places are still under discussion, we capture the 
> discussion 
> > in the draft and continue the discussions on the WG mailing list.
> >
> > John
> >
> >

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 13 Jun 2007 17:21:07 +0200

Sam,

even if we collect fragmented input I think it is better to fill the 
sections first.
The overview can be build upon summarizing the given input .

tele
Sam Xia wrote:
>>>> I would keep the same working areas and explore sub items 
>>>>         
>> as follow.
>>     
>> related to 

-- 
Dr. Telemaco Melia			[email-masked]
Senior Research Staff Member		Tel: +49 (0) 6221 4342- 142
NEC Europe Ltd.				Fax: +49 (0) 6221 4342- 155
Network Laboratories			Web: http://www.netlab.nec.de
Kurfuersten-Anlage 36			       
69115 Heidelberg
GERMANY   

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: <[email-masked]>
Date: Wed, 13 Jun 2007 18:50:47 -0500

this looks OK to me.  I can also contribute to the Security
Considerations as well.

John 

>Sent: 11 June, 2007 05:16
>To: Loughney John (Nokia-NRC/PaloAlto)
>> if some places are still under discussion, we capture the discussion