Subject: [Mipshop] FW: review of draft-ietf-mipshop-mstp-solution

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Jun 2008 12:53:26 -0400

Gorry Fairhurst has provided some observations on the mstp-solution 
draft. Thank you!

See below for the details, and please address these issues along with 
the AD review issues in the next version of the draft:

> These observations relate to:
> http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04
>
> - I have not worked through the DHCP issues, since these are already 
> in discussion, and I am not expert in this area.
>
> - Figure 5: I'd assume that DNS also runs over TCP and UDP?
>
> - Section 6.1
>   "a
>    limit MUST be set on the size of the MIH message, unless
>    fragmentation functionality is added to the MIH layer or IP layer
>    fragmentation is used instead"
> - True, what is this limit?
> - Is it 512 bytes?
> - Is it some chosen number based on interface MTU and allowance for 
> tunnel/security headers?
> - It seems strange to have a MUST but no defined value.
>
> - Second point "or IP fragmentation".
> - I'd prefer not to encourage this option, see section 3.2 of:
> http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines-07
> If the additional requirements apply, then this document could follow 
> the text in the above document and cite it as a reference. At the 
> moment this seems more like commentary.
>
> - Section 6.1
>   "Even short messages can be split
>    across two segments.  This can also cause unacceptable delays"
> - True, TCP can split the message, but is this really the casue of 
> delay. If one uses the PUSH bit, then the records should be sent,, 
> even when no more data follows?
>
> - Section 6.2
>   "On the other hand, if UDP
>    is used, a rate-limiting effect similar to the one obtained with TCP
>    may be obtained by adequately adjusting the parameters of a token
>    bucket regulator as defined in the MIH specifications [IEEE80221].
>    Recommendations for tocken bucket parameter settings are specific to
>    the scenario considered."
> - I think this commentary effectively says very little, and so leaves 
> it for operators to choose to do what they like. I'd suggest this is 
> not good practice. It seems to recognise a problem, but be unwilling 
> to address it.
>
> - Section 6.3
>   "This approach does not include an exponential backoff and
>    therefore tends to degrade more gracefully than TCP when the packet
>    loss rate becomes large, in the sense that the expected delay does
>    not increase exponentially.  The number of retransmissions is
>    limited, which reduces head-of-line blocking of other MIH messages,
>    but this can cause important ES/CS messages to be lost."
>
> - So, is the UDP retransmission backed-off at all, as recommended in:
> http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines-07
> - If the number of retransmissions is limited, what specifies this limit?
>
> ----
>

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 06 Jun 2008 17:35:36 +0200

I have a few comments below, which try to offer answers to your questions.

Best wishes,

Gorry

Nada Golmie wrote:
> Hi Gorry,
> 
> Thanks for the review. Please see possible solutions to your comments 
> below.
> 
> Jari Arkko wrote:
> Obviously this statement needs to be modified based on the latest 
> changes of the MIH specs. Although,
> MIH fragmentation was recently added during sponsor letter ballot 
> comment resolutions, its use is precluded
> with the IP transport.  
>
I agree. So, I understand that this should be phrased "MUST NOT be used
with... [ref]."

> It is also assumed in the MIH specs that  
> finding the path MTU size is outside the scope of the MIH specifications.
> Can we change the above statement to read:
> "a limit MUST be set on the size of the MIH message based on the path MTU."
>
I think a little more is needed here...

Is this any good: "An MIH application SHOULD NOT send UDP essages that
result in IP packets that exceed the MTU of the path to the destination,
i.e. trigger IP fragmentation."

This is what I would suggest is the default for UDP:

"Applications SHOULD NOT send UDP messages that exceed the current PMTU
(or the minimum where PMTU discovery is not implemented).  The minimum
PMTU depends on the IP version used for transmission, and is the lesser
of 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for
IPv6 [RFC2460], although applications may reduce these values to guard
against the presence of tunnels.

> I agree with this and I'd say let drop this statement if we hadn't added 
> following a review.
>
Do you recall the specific issue?

>>> - True, TCP can split the message, but is this really the cause of 
> should add the statement "This can also cause unacceptable delays unless 
> the PUSH bit is set"
>
I think I'd prefer, "the use of the PUSH bit can alleviate this problem
by triggering transmission of a segment less than the SMSS".

> are there recommendations to token bucket parameters that we can include 
> here?

If the application knows the RTT, the rate can be based upon this.

If not, then on average it SHOULD NOT send more than one UDP message
every 3 seconds.

> The default number of retransmissions is set to 2 and retransmissions 
> are controlled by a timer with a default value of 10s. No back-off 
> mechanism is specified.
> 
Sounds fine (10 seconds seems large enough to me). I suggest you add
your text.

> Best wishes,
> -Nada

---

From: "Telemaco Melia (tmelia)" <[email-masked]>
Date: Mon, 9 Jun 2008 13:35:14 +0200

Hi Jari,

Please find inline answers to your questions. AAA-DCHP issue is kept
separate in the previous thread.

Cheers,
Telemaco

>    DHCP  Dynamic Host Configuration Protocol: a protocol described in
>       [RFC2131 <http://tools.ietf.org/html/rfc2131>] that allows
Internet devices to obtain IP addresses,
>       subnet masks, default gateway addresses, and other IP
>       configuration information from DHCP servers.
>   

IPv6 needs to be covered as well. Please add the appropriate reference.

[TELE] Agree.

>    Different types of MoS can be provided independently of other types
>    and there is no strict relationship between ES, CS and IS, nor is
>    there a requirement that the entities that provide these services
>    should be co-located.  However, while IS tends to involve a large
>    amounts of static information, ES and CS are dynamic services and
>    some relationships between them can be expected, e.g., a handover
>    command (CS) could be issued upon reception of a link event (ES).
>    Hence, while in theory MoS can be implemented in different
locations,
>    it is expected that ES and CS will be co-located, whereas IS can be
>    co-located with ES/CS or located elsewhere.  Therefore, having the
>    flexibility at the MSTP to discover different services in different
>    locations is an important feature that can be used to optimize
>    handover performance.  MoS discovery is discussed in more detail in
>    Section 5
<http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#section-
5>.
Is there a need to state that ES/CS is more likely to be associated with
a visited network than home?

[TELE] We thought that giving a bit of context on MIH deployment would
help people not familiar with 802.21. If you believe this is not
relevant for this document we can shorten the text and just state that
we do not make any assumption on the location of the MoS (although there
are some preferred configurations).

>    The configuration of the MoS could be executed either upon network
>    attachment or after successful IP configuration.  The methodology
to
>    be used depends on the considered deployment scenario.
>   
First, there's a problem here with what kind of network attachment we
are talking about. I believe mobility services need to be provided from
the access network in many situations. IP layer configuration is
somewhat independent of the link layer attachments, given things like
bridging, access concentrators, tunneling, proxy MIP and so on. Given
this, I think the above needs to say that discovery happens upon initial
or changed link layer attachment.

Secondly, the part about IP configuration needs to talk about changed IP
configuration as well.  If your DHCP lease expires, and you get a new
address, will you redo discovery? What if you generate a new 3041
address? If the prefixes in the RAs change without the routers
themselves being changed? What if you do DNAv4 or v6 and detect a
network change?

Thirdly, I do not think it is appropriate to leave this entirely to
deployments. At least for the mobile node side, code needs to be written
and every host needs to be able to behave in the correct manner.

In conclusion, this text needs to be written in a much more detailed and
specification-like manner. It may be that subsequent sections contain at
least some of these details. If so, forward references would be needed.

[TELE] OK, we will work on it. A comment about location of the MoS:
there are situations in which it (e.g. IS) may not be provided by the
visited network.

>    In the case where MoS is provided locally (scenarios S1 and S2) ,
the
>    discovery techniques described in
[I-D.ietf-mipshop-mos-dhcp-options
<http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-I-D.
ietf-mipshop-mos-dhcp-options>]
>    and [I-D.ietf-mipshop-mos-dns-discovery
<http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-I-D.
ietf-mipshop-mos-dns-discovery>] are both applicable and
>    either one MAY be used to discover the MoS.
>   

Dns-discovery requires starting from a known domain name, which seems to
exclude using it for local networks. Other than as a follow-up to other
methods, like DHCP.

[TELE] Your question is addressed later in section 5.2. We can modify
the text by deleting "and either one MAY be used to discover the MoS"
and adding forward references to section 5.1 and 5.2.

>    In the case where MoS is provided in the home network while the MN
is
>    in the visited network (scenario S3), the DNS based discovery
>    described in [I-D.ietf-mipshop-mos-dns-discovery
<http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-I-D.
ietf-mipshop-mos-dns-discovery>] is applicable,
>    while the DHCP based discovery method would require an interaction
>    between the DHCP and the AAA infrastructure, similarly to what is
>    specified in [I-D.ietf-mip6-bootstrapping-integrated-dhc
<http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-I-D.
ietf-mip6-bootstrapping-integrated-dhc>] .  This
>    latter case assumes that MoS assignment is performed during access
>    authentication and authorization.
>   
I would like to see this simply state that DHCP based discovery in such
a scenario is inappropriate for the given reasons. I do not believe it
is beneficial to start bundling DHCP with other parts of the network,
except where absolutely required.

[TELE] OK, this refers to the other thread on scenario 3. 

>    It should be noted that authorization of a MN to use a specific MoS
>    server is not in scope of this document and is specified in
>    [IEEE80221
<http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-IEEE
80221>] . 
This needs expansion. How does the IEEE scheme affect the transport
protocol? Can we end up in a situation where DHCP discovery delivers a
server address which refuses to talk to us, for instance?

[TELE] Current 802.21 specifications do not address (yet) authorization
mechanisms. If the Security Study group is formed than it will address
this issue. In any case, MoS server allocation can be based on policies
which are independent of the discovery mechanism used by the MN. 
It is enough to state that while allocation policies are not in scope of
this document they do not impose requirements on the transport/discovery
protocol? 

> In order to use that
> mechanism, the MN MUST first find out the domain name of its home 
> network.  Home domains are usually pre-configured in the MNs (i.e.
> subscription is tied to a network), thus the MN can simply read its 
> configuration data to find out the home domain name (scenario S1).
This is formulated in a peculiar way. Wouldn't it be simpler to just say
that MNs must be configured with the domain name of their home network?

[TELE] OK. 

> Alternatively, the MN
> MAY use the DHCP options for MoS
> discovery[I-D.ietf-mipshop-mos-dhcp-options] as shown in Figure 6b.
Again, binding the DHCP process with AAA, knowledge of particular node's
home network etc is undesirable. Can we remove this from the draft?

[TELE] Discussion on the separate thread already started.

>    DHCP --  In order to find out the domain name of the local network,
>       the MN SHOULD use the dhcpv4 option 15 for learning the domain
>       name [RFC2132 <http://tools.ietf.org/html/rfc2132>].  A similar
solution is available for dhcpv6
>       [I-D.ietf-dhc-dhcpv6-opt-dnsdomain
<http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-I-D.
ietf-dhc-dhcpv6-opt-dnsdomain>] .
The draft is expired. I would suggest re-considering whether this
approach (dchp + dns) is necessary.

[TELE] Thanks for the good catch. We will discuss this.

>    Reverse dns query --  When DHCP does not provide the required
domain
>       name, the MN MAY use reverse DNS (DNS PTR record) to find the
>       domain name associated with the IP address it is using in the
>       visited network.  Note, that when a NAT device exists between
the
>       MN and the visited network, the MN will first need to find out
the
>       external IP address of the NAT device.  Some possible methods
for
>       determining the NAT's external IP address are STUN [RFC3849
<http://tools.ietf.org/html/rfc3849>] or
>       UPnP [UPnP_IDG_DCP
<http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-UPnP
_IDG_DCP>].  Once the MN has determined the external IP
>       address of the NAT device, it MUST use that address in the
reverse
>       DNS query.
A lot of complexity. I wonder if this is really needed. Anyone who is
willing to deploy a relatively costly service such as the MIS on their
network, why would they not be willing to add a few DHCP options to
their network as well? Note that you do not need to use DHCP in IPv6 to
acquire such options; stateless DHCP would also do fine, and can be
combined with autoconfig addresses.

[TELE] So we assume the domain name of the local network must be
available through DHCP? 

>    When the discovery of an MoS at the visited network, using the FQDN
>    returned in the reverse DNS query, is not successful, the MN MAY
>    attempt to remove portions from the left side of the FQDN and
attempt
>    discovery again.  The process MAY be repeated iteratively until a
>    successful discovery.
As in eventually asking for mobility services from .com, for instance? I
think you need text to avoid this from happening.

[TELE] Agree. We will modify accordingly.

>    This section assumes the use of IPv6 and DHCPv6 based mechanisms to
>    discover MoS services in home while the MN is in visited network.
If
>    similar functionalities are desired for IPv4 additional DHCPv4
>    extensions would be required.  Since use cases requiring these
>    extensions were not identified at the time of writing this
document,
>    they were excluded from the scope of the document.

I am surprised by this. Generally speaking, I would expect to see
feature parity for IPv4 and IPv6 in specifications like this.

[TELE] We had extensive discussions about this and I agree with you. We
will reflect the changes in the new ID.

>    To discover an MoS in a remote network other than home network, the
>    MN MUST use the DNS based MoS discovery method described in
>    [I-D.ietf-mipshop-mos-dns-discovery
<http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-I-D.
ietf-mipshop-mos-dns-discovery>].  The MN MUST first learn the
>    domain name of the network containing the MoS it is searching for.
>    If the MN does not yet know the domain name of the network,
learning
>    it may require more than one operation, as DHCP based discovery can
>    not be used and pre-configuration is not a feasible solution in
case
>    of an arbitrary remote network.  The MN MAY attempt to first
discover
>    an MoS in either the local or home network (as in Figure 9 part
(a))
>    and query that MoS to find out the domain name of a specific
network
>    or the domain name of a network at a specific location (as in
>    Figure 9 part (b)).  Alternatively, the MN MAY query an MoS
>    previously known to learn the domain name of the desired network
>    (e.g., via an IS Query).  Finally, the MN MUST use DNS queries to
>    find MoS in the remote network as inFigure 9 part(c).  It should be
>    noted that step c can only be performed upon obtaining the domain
>    name of the remote network.
The part about finding more information from MoS to redirect the mobile
node to a third party is vague. Can this document point to specific
attributes defined in IEEE that would carry such information? Otherwise
this cannot be implemented.

[TELE] IEEE 802.21 defines information elements such as OPERATOR_ID and
SERVICE_PROVIDER_ID which can be a domain name. Therefore by MoS query,
it is possible to find it out. We can refer to IEEE D10.0 version, Annex
B. 

Also, its not clear why "pre-configuration is not a feasible solution in
case of an arbitrary remote network". Surely its no harder to configure
a given 3rd party network than a given home network. I agree that
pre-configuration should be avoided if possible, though.

[TELE] We were just arguing that configuring n-times can be an issue,
especially if 3rd party MoS are deployed in an over the top manner.

> while it is preferred to avoid using MIH ACKs with TCP
>    since TCP includes acknowledgement and retransmission
functionality.
Is there no need for application level confirmation? TCP ACKs will only
tell you that the message got through, not, for instance, that it can be
obeyed.

[TELE] MIH CS messages are always request-response and contain the
result of the requested operation (e.g. link scan, link switch, etc...).
ACKs messages in this case are always about message reception
confirmation. We argue that it is not desirable from a performance point
of view to implement ACKs both at transport layer (TCP) and at
application level (MIH). 

> On the other hand, if UDP
> bucket regulator as defined in the MIH specifications [IEEE80221
<http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-IEEE
80221>].
> the scenario considered.
The parameters and algorithms governing the use and timing of UDP need
to be specified. Its fine to point to an IEEE spec, but it needs to be
clear that they are mandatory. From the above I cannot  determine what
an implementation needs to do.

[TELE] Currently in IEEE rate limiting mechanism is implementation
specific and it recommends using RFC 4443. We can refer to RFC 4443 and
align .21 specs to it. Gorry already commented some figures.

> As [RFC4787 <http://tools.ietf.org/html/rfc4787>] requires a minimum 
> state timeout of two minutes or more, MIH messages using UDP as 
> transport SHOULD be sent once every two minutes.

This is too vague. Sent when? If you have an implementation capable of
using MIH? When you have something to send, you keep sending it over and
over again? When you have something to receive you keep sending
something else? How do you know when you have something to receive, or
when you want to receive something?

[TELE] Again the signaling method is request-response. The .21 draft
specifies what messages are expected to be received and when. Here we
simply argue how an MIH function using UDP + MIH ACKs could deal with
NAT. 

Note that it would be very unfortunate if every host in every network
that had turned MIH on would be sending a packet every 2 mins.

[TELE] ES messages are asynchronous and are sent to the network upon
events happening in the remote stack (MN). Since hosts are mobile and
wireless conditions can vary quite frequently events can be triggered
quite often. These parameters are configured in the MIHF. Should we
reference to it?
(See Gorry's comment).

> MIH messages sent over UDP, TCP or other supported
>    transport MUST use the default port number defined for that
>    particular transport.
Where are these specified?

[TELE] Section 9 request IANA ports.

> MIH Transport Options
The document is very silent on how MIH messages are carried on a given
transport protocol. At the very least the draft should indicate that no
extra framing is needed because IEEE specs already contain a length
field.

[TELE] OK, we can specify this in section 4. 

> MIH Transport Options

The document does not talk about how servers know the capabilities of
clients that send event/command services to. Is this a part of the IEEE
definitions, and you subscribe to a particular event stream? In any
case, the document should talk about this and point to the relevant
other specifications where needed.

[TELE] MIH server capabilities discovery and MIHF registration are part
of the .21 spec. We can refer to the necessary section if required.

>    In the case where DHCP is used for node discovery and
authentication
>    of the source and content of DHCP messages is required, network
>    administrators SHOULD use DHCP authentication option described in
>    [RFC3118 <http://tools.ietf.org/html/rfc3118>], where available or
rely upon link layer security.  This
>    will also protect the DHCP server against denial of service attacks
>    to.  [RFC3118 <http://tools.ietf.org/html/rfc3118>] provides
mechanisms for both entity authentication and
>    message authentication.

I think the overall recommendation is good, but practically no one is
going to deploy RFC 3118. With this in mind, I would like to see the
above paragraph explain in more detail the security implications of
relying on link layer security.

[TELE] We will add more text.

>    In the case where reliable transport protocol such as TCP is used
for
>    transport connection between two MIHF peers, TLS [RFC4346
<http://tools.ietf.org/html/rfc4346>] SHOULD be
>    used for message confidentiality and data integrity.  In
particular,
>    TLS is designed for client/server applications and to prevent
>    eavesdropping, tampering, or message forgery.  Readers should also
>    follow the recommendations in [RFC4366
<http://tools.ietf.org/html/rfc4366>] that provides generic
>    extension mechanisms for the TLS protocol suitable for wireless
>    environments.
>
>    In the case where unreliable transport protocol such as UDP is used
>    for transport connection between two MIHF peers, DTLS [RFC4347
<http://tools.ietf.org/html/rfc4347>]
>    SHOULD be used for message confidentiality and data integrity.  The
>    DTLS protocol is based on the Transport Layer Security (TLS)
protocol
>    and provides equivalent security guarantees.
>
>    Alternatively, generic IP layer security, such as IPSec [RFC4301
<http://tools.ietf.org/html/rfc4301>] MAY
>    be used where neither transport layer security for a specific
>    transport is available nor server only authentication is required.
>   
Too many options. I do not see a particular requirement for IPsec here,
why do we need to include it? 

[TELE] IEEE MIH protocol does not have any security yet and that's why
we did not mandate anything here. Keeping all options open. 

Also, are TLS and DTLS mandatory to implement?

The explanation on how to use TLS and DTLS seems thin. Is there
something to be said about what type of certificates or infrastructure
is needed, what modes of operation are allowed, etc?

[TELE] We will come up with some more concise explanation.   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Telemaco Melia (tmelia)
Sent: Wednesday, May 21, 2008 4:04 PM
To: Jari Arkko
Cc: [email-masked];
[email-masked]; Mipshop
Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-mstp-solution

Hi Jari,

Before discussing fine granular issues we would like to focus on the
major concern you raised, the AAA-DHCP binding and the applicability of
scenario 3.

Let me quote some text from 3GPP TS 24.302, UE procedures about ANDSF
discovery  (section 6.8.2.2), dealing with discovery of MoS in home when
the UE is attached in visited network.

"...The ANDSF is located in the subscriber's home operator network. The
ANDSF can provide assistance information at any time to the UE. Also,
the UE can send a request to the ANDSF in order to get assistance
information for access network discovery and selection..."

"If the IP address of the ANDSF is not provisioned in the UE, the UE
shall perform DNS or DHCP procedure in order to retrieve the IP address
of the ANDSF."

"Editor's note: Other solution for the UE to retrieve the IP address of
the ANDSF is FFS"

When using DHCP, the best way to ensure the use of an ANDSF in the home
PLMN is to push the address of the ANDSF to the MN during the
authentication phase. In ID draft-ietf-mipshop-mstp-solution the home
network can enforce the use of a specific MoS even when the MN is
roaming. When using DHCP, AAA-DHCP binding is the only possible way.

We could add text to scenario 3 saying that when DHCP based discovery
fails the MN should run DNS queries. 

A comment about your suggested solution (c) local MIH IS + redirection
to home MIH.

Are you referring to proxy functionalities? If yes this is not supported
by MIH. 

What do you think?

telemaco

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Monday, May 19, 2008 6:35 PM
To: Telemaco Melia (tmelia)
Cc: [email-masked]; Mipshop;
[email-masked]; [email-masked]
Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-mstp-solution

Telemaco,

> The DHC WG so far was not involved upon suggestion of the Mipshop 
> chairs.
>   

Right, but see Vijay's mail. We do need to talk to them at this stage.
That's OK, we ship a lot of documents via them...

> As for the transport review, Gorry has been added to the MIH DT mailer

> since Chicago.
> In Vancouver last winter, together with Nada, we answered the open 
> questions/issues Gorry had.
>   

Right, and that's been great. But I don't recall there was ever a formal
directorate review, was there? And since I'm not on the DT mailing list,
have you Gorry reviewed the most recent mstp draft as well? Any thoughts
on the questions below?

Jari

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 23 Jun 2008 14:25:40 -0400

Hi Jari, 

I haven't seen your response to Telemaco on this. 

You had suggested 

> (a) local MIH
> services, (b) configured home network name and DNS, (c) local MIH IS +
> redirection to home MIH, (d) other Internet service discovery 
> mechanisms

We already support (a) and (b). (c) needs further thought. Are you
thinking about some sort of a re-direct message from the local MIH
server to the mobile node, re-directing the mobile node to the MIH
server in the home network? The question then would be, how does the
local MIH server get the IP address of the remote MIH server?

We could work on (d), but we need to scope the work.

It looks like re-using the MIPv6 integrated scenario mechanisms, is the
simplest approach for providing the MIH server information from the home
network to the mobile node during access authentication. 

Vijay

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Telemaco Melia (tmelia)
> Sent: Wednesday, May 21, 2008 7:04 AM
> To: Jari Arkko
> > Regards,
> > Behalf Of Jari Arkko
> > Sent: Monday, May 19, 2008 2:21 PM
> > To: [email-masked]; Mipshop
> > Subject: [Mipshop] AD review of draft-ietf-mipshop-mstp-solution
> >
> > Hi all,
> >
> > I have made my AD review of this document. Please find 
> details below.
> > Overall, there were a few important missing or underspecified parts 
> > relating to parameters and algorithms for using UDP, discovery via 
> > another MoS, NAT-traversal retransmissions, and 
> authorization. These 
> > should be specified. The security mechanisms should be 
> narrowed down 
> > to a more reasonable set.
> >
> > But the big question for me was whether it is appropriate to employ 
> > DHCP-AAA binding so that per-MN information can be 
> provided. I realize
> 
> > that we have done it once in the context of the Mobile IP 
> > bootstrapping work. But frankly, that sets a very high bar for 
> > deployment in a given access network and introduces 
> dependencies and 
> > complexity that is undesirable. In general, if every 
> application that 
> > wants to avoid configuration needs to have special support in DHCP 
> > relays, it becomes very hard to deploy anything new. My read of RFC 
> > 5164 does not say that the AAA binding is required. My question is 
> > whether (a) local MIH services, (b) configured home network 
> name and 
> > DNS, (c) local MIH IS + redirection to home MIH, (d) other Internet 
> > service discovery mechanisms would be sufficient or 
> preferable. At the
> 
> > very least, we should consider publishing the simple 
> solution first, 
> > and only if there's actual evidence of deployments with 
> more complex 
> > requirements, consider extending it.
> >
> > Process:
> >
> > Given the extensive use of DHCP in this document, we need to engage 
> > the DHC WG in a discussion of this draft. I would also like 
> to see a 
> > transport directorate review. Both to be done after a revision 
> > addressing my own comments has been submitted, however.
> >
> > Technical:
> >
> >   
> > Is there a need to state that ES/CS is more likely to be associated 
> > with a visited network than home?
> >
> >   
> > are talking about. I believe mobility services need to be provided 
> > from the access network in many situations. IP layer 
> configuration is 
> > this, I think the above needs to say that discovery happens upon 
> > initial or changed link layer attachment.
> >
> > Secondly, the part about IP configuration needs to talk 
> about changed 
> > IP configuration as well.  If your DHCP lease expires, and 
> you get a 
> > new address, will you redo discovery? What if you generate 
> a new 3041 
> > deployments. At least for the mobile node side, code needs to be 
> > written and every host needs to be able to behave in the correct
> manner.
> >
> > In conclusion, this text needs to be written in a much more 
> detailed 
> > and specification-like manner. It may be that subsequent sections 
> > contain at least some of these details. If so, forward references
> would be needed.
> >
> >   
> > Dns-discovery requires starting from a known domain name, 
> which seems 
> > to exclude using it for local networks. Other than as a 
> follow-up to 
> > other methods, like DHCP.
> >
> >   
> > I would like to see this simply state that DHCP based discovery in 
> > such a scenario is inappropriate for the given reasons. I do not 
> > believe it is beneficial to start bundling DHCP with other parts of 
> > the network, except where absolutely required.
> >   
> > This is formulated in a peculiar way. Wouldn't it be 
> simpler to just 
> > say that MNs must be configured with the domain name of their home
> network?
> >
> >   
> >> Alternatively, the MN
> >> discovery[I-D.ietf-mipshop-mos-dhcp-options] as shown inFigure 6b.
> >>     
> > Again, binding the DHCP process with AAA, knowledge of particular 
> > node's home network etc is undesirable. Can we remove this from the
> draft?
> >
> >   
> <http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-UP
> > nP _IDG_DCP>].  Once the MN has determined the external IP
> >   
> > their network as well? Note that you do not need to use 
> DHCP in IPv6 
> > to acquire such options; stateless DHCP would also do fine, 
> and can be
> 
> > As in eventually asking for mobility services from .com, 
> for instance?
> 
> > I think you need text to avoid this from happening.
> >
> >   
> > The part about finding more information from MoS to redirect the 
> > mobile node to a third party is vague. Can this document point to 
> > specific attributes defined in IEEE that would carry such 
> information?
> 
> > Otherwise this cannot be implemented.
> >
> > Also, its not clear why "pre-configuration is not a 
> feasible solution 
> > in case of an arbitrary remote network". Surely its no harder to 
> > configure a given 3rd party network than a given home 
> network. I agree
> 
> > that pre-configuration should be avoided if possible, though.
> >
> >   
> > Is there no need for application level confirmation? TCP ACKs will 
> > only tell you that the message got through, not, for 
> instance, that it
> 
> > can be obeyed.
> >
> >   
> > using MIH? When you have something to send, you keep 
> sending it over 
> > and over again? When you have something to receive you keep sending 
> > transport protocol. At the very least the draft should 
> indicate that 
> > no extra framing is needed because IEEE specs already 
> contain a length
> 
> > field.
> >
> >   
> >> MIH Transport Options
> >>     
> >
> > clients that send event/command services to. Is this a part of the 
> > IEEE definitions, and you subscribe to a particular event 
> stream? In 
> > any case, the document should talk about this and point to the 
> > relevant other specifications where needed.
> >
> >   
> > Too many options. I do not see a particular requirement for IPsec 
> > here, why do we need to include it?
> >
> > Editorial:
> > Acronyms used before defined. At least for MSTP (!) and MIHF, maybe 
> > others. Expand them on first use, if this happens prior to 
> the terms 
> > section.
> >
> > Most entries in Section 2 need to point to the relevant RFC 
> or other 
> > specification that defines them. E.g., NAI or ES.
> >
> > Fix these idnits issues:
> >
> >   == Unused Reference: 'I-D.ietf-dime-mip6-integrated' is 
> defined on 
> > line
> >      1066, but no explicit reference was found in the text
> >
> >   -- Unexpected draft version: The latest known version of 
> >      draft-ietf-mip6-bootstrapping-integrated-dhc is -hc, 
> but you're 
> > referring
> >      to -06.
> >
> >
> >   
> >> Since transporting long MIH messages may require
> >>    fragmentation that is not available in UDP, ...
> >>     
> > This needs to be reformulated. UDP itself has no fragmentation 
> > support, but IP does. But the issue is that IP layer 
> fragmentation may
> 
> > not work well, particularly for large packets, may cause 
> several other
> 
> > issues, etc.
> >
> >   
> >> TCP client
> >>     
> > I believe it would be more appropriate to talk about the 
> "MSTP client"
> > or "MIH client" or "MSTP TCP client"; TCP does not operate 
> on its own.
> > Or, maybe you can merge "TCP client" and "MIHF" in Figure 10.
> >
> > (Appears in multiple places in the document, as does the 
> corresponding
> 
> > UDP term)
> >   
> >>    and responses may cause DoS and the inability of the MN 
> to perform
> 
> >> a
> >>     
> > Acronym "DoS" not introduced earlier.
> >
> > Jari
> >

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Jun 2008 16:02:29 +0300

Sorry it took a long time to respond on this thread. I wanted to get 
some background on the 3GPP case first. And I have been busy with other 
issues as well :-(

> are some preferred configurations).

OK

> [TELE] OK, we will work on it.

Good.

> A comment about location of the MoS:

OK

> and adding forward references to section 5.1 and 5.2.

OK

> this document they do not impose requirements on the transport/discovery

Hmm. I don't think its sufficient.

Currently there is no authorization mechanisms in 802.21 itself, but 
there might be in the future.

If you turn on TLS security between the mobile and server, I think you 
want to do it with server certs only, in http style (note: the usage of 
TLS is not very well explained in the spec; I think you need to expand 
on that). With server-side certs you would not have any client 
authorization model, but again that is something that future extensions 
could address.

I don't think you need to develop all of these techniques to the current 
document. However, you need to employ truth in advertising as well as 
prepare for the future where something might be checking for the 
authorization:

- be clear that you do not provide any authorization mechanism either 
here or in the 802.21 side
- that you assume this is deployed in environments where all devices can 
access this service
- that if in the future there is something at 802.21 layer or elsewhere 
that checks for the authorization, the mobile nodes fall back to other 
servers they have learned of, rather than simply failing after first 
failure with one server

> [TELE] Thanks for the good catch. We will discuss this.

Any results of the discussion?

> [TELE] So we assume the domain name of the local network must be

Either that, or, just have the MIS server address being available via 
DHCP. I understand the need for home-network based services. But what 
you are talking about here is something that (a) helps the handoffs in 
local access network and (b) requires some change in the access network 
anyway, be it DHCP or DNS. For the people who want to deploy this in 
access networks, I'm not sure we need multiple mechanisms.

> [TELE] Agree. We will modify accordingly.

Ok. Any text available yet?

> will reflect the changes in the new ID.

Good, thanks.

> it is possible to find it out. We can refer to IEEE D10.0 version, Annex

OK.

> especially if 3rd party MoS are deployed in an over the top manner.

Ok, but please reformulate the text to make this point clearer.

> of view to implement ACKs both at transport layer (TCP) and at

OK

> align .21 specs to it. Gorry already commented some figures.

OK. But I think this needs to be a part of your spec rather than 
something you leave to implementations.

> simply argue how an MIH function using UDP + MIH ACKs could deal with

It does not help that they are of the request-response form. You need to 
specify what the messages to be used for keepalive are, or point to the 
relevant parts of the IEEE spec.

> quite often. These parameters are configured in the MIHF. Should we

Yes you should.

> [TELE] Section 9 request IANA ports.

Right, but please place the TBD-BY-IANA here as well.

> of the .21 spec. We can refer to the necessary section if required.

Yes, please do.

> we did not mandate anything here. Keeping all options open. 

Were are in the IETF to produce a spec that people can follow. This 
includes agreeing on some specific way to implement particular protocol 
functions, including security. I would recommend simply picking TLS and 
not listing the other options.

> [TELE] We will come up with some more concise explanation.   

Ok.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Jun 2008 16:11:46 +0300

Vijay ,

> local MIH server get the IP address of the remote MIH server?

But all solutions face the same problem. If the entity that needs to 
hand the address to the mobile node is in the access network, and we 
wanted to give the address of a server in the home network, and the 
mobile node has no understanding of its home network, what do you do? 
Obviously we can play with various local configuration, AAA delivery, 
etc, tricks, but at the end of the day, a node in the access network 
makes this happen.

And I think that if a server does this in the access network and 
provides a response, its much cleaner than trying to affect some other 
piece of network infrastructure (e.g., DHCP relays) to deliver the same 
per-client answer.

> We could work on (d), but we need to scope the work.

Lets first decide whether (d) is needed. Guidance for this might be 
gotten from people who are interested in deploying MSTP?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Jun 2008 17:07:19 +0300

Telemaco,

And now I want to return to the big question about the binding between 
DHCP and 802.21 provisioning.

First, I think you'll agree that if every application that didn't know 
where its home server was needed to upgrade the DHCP infrastructure, 
we'd be in trouble. It does not scale, it faces very high deployment 
barriers, etc. I don't want to get into a discussion of whether we made 
the right design for Mobile IP bootstrapping, but I certainly don't want 
to extend DHCP relays every second month to support a new feature.

This is also not the first time that we need a solution for such a 
provisioning issue. And, if 3GPP is one of your primary applications, 
its not the first time they have that problem either. There are existing 
protocols that can handle such tasks, such as OMA DM.

My recommendation would be to rely on either preconfiguration of the 
mobile nodes or protocols that already exist for first-time 
configuration tasks.

My understanding is that the 3GPP is discussing whether to apply 802.21, 
MSTP, and so on and that there are also competing designs. If your 
802.21 solution relied on other 3GPP components for the discovery part, 
would that affect your standing in the discussion? (If my information is 
correct, one of the other solutions is OMA DM for the everything and not 
just the discovery part.)

Jari

---

From: "Stefano Faccin" <[email-masked]>
Date: Tue, 24 Jun 2008 12:03:07 -0700

Telemaco,
i must support Jari's views on this. It makes no sense in making such changes. Besides, when and if an SDO decides to use 802.21 and MSTP, even if DHCP is extended the SDO may decide not to use the extensions, thus invalidating the work.

Jari, you're correct, OMA is the alternative being proposed for the whole discovery, not just the server discovery. By the way, one of the key points being raised in favor of OMA DM is security.

Cheers,
Stefano

-----Original Message-----
From: [email-masked] on behalf of Jari Arkko
Sent: Tue 6/24/2008 7:07 AM
To: Telemaco Melia (tmelia)
Cc: [email-masked]; [email-masked]; Mipshop
Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-mstp-solution
 
Telemaco,

Jari

---

From: "Stefano Faccin" <[email-masked]>
Date: Tue, 24 Jun 2008 12:05:55 -0700

Personally, I do not believe that (d) is needed. IMO (a) and (b) are the most probable cases, though e.g. 3GPP is not even liking (a). The thinking is to provide the services always from a node in the home network, in which case (b) can work very well.

Stefano

-----Original Message-----
From: [email-masked] on behalf of Jari Arkko
Sent: Tue 6/24/2008 6:11 AM
To: Vijay Devarapalli
Cc: [email-masked]
Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-mstp-solution
 
Vijay ,

Jari

---

From: <[email-masked]>
Date: Tue, 24 Jun 2008 18:36:05 -0500

Hi All,

Agree with the simplifications suggested by Jari to have just one
discovery method (e.g. DNS or DHCP), not multiple options.

Would like further explanation about why use server side TLS only.
Eliminating the IPSec option would be OK again, for simplifying.

Would like to clarify the 'synchronous' vs 'asynchronous' and 'ACK'
concepts being discussed here. The MIH protocol has ACK to acknowledge
packet delivery regardless of the service (ES CS, IS, SM) The MIH
service layer protocol is 'asynchronous' in the sense that a request or
response packet may originate from either the UE or the network without
previous exchange. Some of the proposals in the ANDSF discussion are to
use MIIS response packets without a corresponding request packet first,
to create the notion of a 'push' from the network to the UE. The CS
already has this behavior, so it is a better match for this behavior...
but the point is that the reviewers should understand this aspect.

BR,
Michael

-----Original Message-----
Behalf Of ext Jari Arkko
Sent: 24 June, 2008 06:02

> we do not make any assumption on the location of the MoS (although 
> there are some preferred configurations).
>   

OK

> from the access network in many situations. IP layer configuration is 
> Secondly, the part about IP configuration needs to talk about changed 
> IP configuration as well.  If your DHCP lease expires, and you get a 
> new address, will you redo discovery? What if you generate a new 3041 
manner.
>
> In conclusion, this text needs to be written in a much more detailed 
would be needed.

Good.

OK

> Dns-discovery requires starting from a known domain name, which seems 
> to exclude using it for local networks. Other than as a follow-up to 

OK

> [TELE] Current 802.21 specifications do not address (yet) 
> authorization mechanisms. If the Security Study group is formed than 
> it will address this issue. In any case, MoS server allocation can be 
> based on policies which are independent of the discovery mechanism
used by the MN.
> It is enough to state that while allocation policies are not in scope 
> of this document they do not impose requirements on the 
> transport/discovery protocol?
>   

> their network as well? Note that you do not need to use DHCP in IPv6 
> to acquire such options; stateless DHCP would also do fine, and can be

> As in eventually asking for mobility services from .com, for instance?

> [TELE] We had extensive discussions about this and I agree with you. 
> We will reflect the changes in the new ID.
>   

Good, thanks.

> specific attributes defined in IEEE that would carry such information?

> [TELE] IEEE 802.21 defines information elements such as OPERATOR_ID 
> and SERVICE_PROVIDER_ID which can be a domain name. Therefore by MoS 
> query, it is possible to find it out. We can refer to IEEE D10.0 
> version, Annex B.
>   

OK.

> Also, its not clear why "pre-configuration is not a feasible solution 
> configure a given 3rd party network than a given home network. I agree

> only tell you that the message got through, not, for instance, that it

> confirmation. We argue that it is not desirable from a performance 
> point of view to implement ACKs both at transport layer (TCP) and at 
> application level (MIH).
>   

OK

> specific and it recommends using RFC 4443. We can refer to RFC 4443 
> and align .21 specs to it. Gorry already commented some figures.
>   

> using MIH? When you have something to send, you keep sending it over 

Yes you should.

> IEEE definitions, and you subscribe to a particular event stream? In 
> [TELE] MIH server capabilities discovery and MIHF registration are 
> part of the .21 spec. We can refer to the necessary section if
required.

Yes, please do.

Ok.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 25 Jun 2008 05:58:26 +0300

Michael,

> discovery method (e.g. DNS or DHCP), not multiple options.

A small clarification. I believe we do need both DNS and DHCP discovery 
methods, but that the DNS method would be primarily reserved for the 
case where you know your home domain and try to access the server from 
there. And DHCP would be reserved for discovering the local server 
address. What I saw as potentially unnecessary was a combination of DHCP 
and DNS to discover a local server.

> Eliminating the IPSec option would be OK again, for simplifying.

The server-side only vs. both side issue refers to the authentication 
model. That is, which side is authenticated and which side has 
certificates; both sides would still have to implement TLS. I think the 
selection of supporting server-side only vs. both is up to you. I 
believe the server-side only approach has been used successfully on many 
other similar contexts and that's something that you should at least 
support. If you want to specify a mode where the mobile nodes too are 
authenticated by their own certificates, that is fine.

> but the point is that the reviewers should understand this aspect.

OK. Thanks for the explanation.

Jari