Re: [Mipshop] Comments on draft-ietf-mipshop-mstp-solution-03

[Behcet Sarikaya <[e-mail]>]

Hi Vijay,
  Here are my comments:
1. I had the same concern about draft-rahman-mipshop-mih-transport-03. I think that this is a sticky issue, I would like to see the authors' response.

2. Regarding Scenario S2, 
In this scenario, the MN is in the visited network and mobility
   services are provided by the visited network.However I saw presentations which said: 

MN is in the visited network and MIH services are provided by the home network 

Which one is correct?

3. Regarding the scenarios S1-S3, the scenarios stipulate that MoS service will be provided by a single operator. However, in some scenarios where MN is multi-homed, such an assumption is too restrictive. It might be the case that we need to remove this restriction and allow the freedom of support by several operators. This can easily be allowed by revising the draft.



Regards,

Behcet

----- Original Message ----
From: Vijay Devarapallli <[e-mail]>
To: [e-mail]; Telemaco Melia (tmelia) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Sent: Thursday, May 8, 2008 11:16:22 PM
Subject: [Mipshop] Comments on draft-ietf-mipshop-mstp-solution-03

Hello,

I was about to prepare the document shepherd writeup for
draft-ietf-mipshop-mstp-solution in order to send the document
to the IESG. But its not ready yet. I went through draft once
more and have a few comments.

 >    IS Information Service: a MoS that originates at the lower or upper
>
>      layers and sends information to the local or remote upper or lower
>      layers.  It can use secure or insecure ports to transport
>      information elements (IEs) and information about various
>      neighboring nodes.

We might have to clarify what "lower" and "upper" layers mean here.
I guess "lower" is anything below IP and "upper" is anything above
the transport layer? What if an event is generated by Mobile IP
(the same "upper" and "lower" terminology is used for ES and CS
information too)?

> Its architecture is outside the scope of the
>      IEEE 802.21 draft document.

Do we care about this in this draft?

>   o  MoS discovery can be performed during initial network attachment
>      or thereafter.

Re-word to

  o  MoS discovery can be performed either during initial network
     attachment or at any time thereafter.

>   The MN could know or not know the realm of the MoS to be discovered.

Re-word to

 The MN may not know the realm of the MoS to be discovered.

>   In any case after the acquisition of the target realm (e.g. via
>   Information Server or statically configured) the MN could either be
>   pre-configured with the address of the MoS, or this address could be
>   obtained through DHCP or DNS.

Something is wrong with the above sentence. Couldn't parse it.

>                              +-------+
>               +----+         |Domain |
>               | MN |-------->|Name   |
>               +----+         |Server |
>                              +-------+
>                [e-mail]
>
>                             (a) using DNS Query
>
>
>
>                            +-----+      +------+
>               +----+       |     |      |DHCP  |
>               | MN |<----->| DHCP|<---->|Server|
>               +----+       |Relay|      |      |
>                            +-----+      +------+
>
>
>                             (b)  Using DHCP Option
>
>    Figure 6: MOS Discovery (a) Using DNS query, (b) using DHCP option

You might want to mention here that the DHCP relay is optional. It
may not always be there between the MN and the DHCP server in the
home network.

> 5.2.  MoS Discovery when MN is in visited network and MoSv is also in
>      visited network (Scenario S2)

>   It should be noted, that the usage of DHCP options to discover an MoS
>   in this particular scenario is recommended because of its simplicity
>   over the DNS based discovery method: the DNS discovery method
>   requires the MN to learn the domain name of the local network first,
>   possibly using DHCP, and then perform the DNS query.  The usage of
>   the DHCP based discovery method does not require any additional
>   procedure.

I think the above paragraph should be re-worded. Its possible that
the visited network has deployed MoS, but not the DHCP extensions
for discovering a MoS server. So the MN should first try using DHCP.
If there is no response, the MN should try to do a DNS lookup for
the MoS server after acquiring the visited network realm information.

> 5.3.  MOS Discovery when the MN is in a visited Network and Services are
>      at the Home network (Scenario S3)

>   The mobile node executes the network access authentication procedure
>   (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS.  The NAS
>   is in the visited and it interacts with AAAh via AAAv to authenticate
>   the mobile node.  In the process of authorizing the mobile node, the
>   AAAh verifies in the AAA profile that the mobile node is allowed to
>   use MoS services.  The AAAh assigns the MoS in the home and returns
>   this information to the NAS.  The NAS may keep the received
>   information for a configurable duration or it may keep the
>   information for as long as the MN is connected to the NAS.

Why is authorization relevant here? I also I wonder why there is
no talk about checking if the MN is authorized for MoS service in
scenarios S1 and S2. Why does authorization become important for
only in scenario S3?

> 6.  MIH Transport Options
>
>   Once the Mobility Services have been discovered, MIH peers MAY
>   exchange information over TCP, UDP or any other transport supported
>   by both the server and client, as described in
>   [I-D.rahman-mipshop-mih-transport].

We are not planning to progress
draft-rahman-mipshop-mih-transport-03 in any form. The above text
seems to suggest that this draft should be an Normative reference.
Why is this reference relevant here?

> 11.1.  Normative References
>
>   [I-D.ietf-dhc-dhcpv6-opt-dnsdomain]
>              Yan, R., "Domain Suffix Option for DHCPv6",
>              draft-ietf-dhc-dhcpv6-opt-dnsdomain-04 (work in progress),
>              June 2007.

You are adding a normative reference to the above draft. I am not
sure what the status of the above draft is. If we leave it as a
normative reference, draft-ietf-mipshop-mstp-solution will not be
published until the DHCPv6 draft is published.

>   [I-D.ietf-dime-mip6-integrated]
>              Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
>              and K. Chowdhury, "Diameter Mobile IPv6: Support for
>              Network Access Server to Diameter Server  Interaction",
>              draft-ietf-dime-mip6-integrated-08 (work in progress),
>              February 2008.
>
>   [I-D.ietf-mip6-bootstrapping-integrated-dhc]
>              Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
>              Integrated Scenario",
>              draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
>              progress), April 2008.

These two should be moved to Informative section. You are referring
to these drafts to say that the solution is similar to these. Thats
all, not using anything from these drafts.

>   [I-D.ietf-tsvwg-udp-guidelines]
>              Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for
>              Application Designers", draft-ietf-tsvwg-udp-guidelines-06
>              (work in progress), April 2008.

Informative. These are just guidelines.

>   [I-D.stupar-dime-mos-options]
>              Korhonen, J. and T. Melia, "Diameter extensions for MoS
>              discovery", draft-stupar-dime-mos-options-00 (work in
>              progress), February 2008.

Informative. Not relevant for implementing the solution described in
this draft.

>   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
>              Internet Protocol", RFC 4301, December 2005.
>
>   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
>              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
>
>   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
>              Security", RFC 4347, April 2006.
>
>   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
>              and T. Wright, "Transport Layer Security (TLS)
>              Extensions", RFC 4366, April 2006.

All of these should be Informative. You are only referring to
them in the security considerations section saying that they can
be used to protect the MIH messages.

>   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
>              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
>              RFC 4787, January 2007.

Informative again.

Telemaco, how soon can you submit a new version? :) As soon as you
submit a new version, it will be shipped to the IESG.

I apologize for bringing up these issues so late. I should I have
done this during the WG last call.

Vijay
_______________________________________________
Mipshop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mipshop