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

From: Jari Arkko <[email-masked]>
Date: Mon, 19 May 2008 15:20:58 +0300

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:

>    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.

>    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?

>    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.

>    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.

>    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.
>    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-IEEE80221>] . 
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?

> 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?

> Alternatively, the MN
> MAY use the DHCP options for MoS
> 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?

>    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.

>    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.

>    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.

>    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.

>    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.

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.

> 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.

> 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 <http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-IEEE80221>].
> Recommendations for tocken bucket parameter settings are specific to
> 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.
> 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?

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.

> 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?

> 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.

> 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.

>    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.

>    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?

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?

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

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

---

From: "Telemaco Melia (tmelia)" <[email-masked]>
Date: Mon, 19 May 2008 15:09:47 +0200

Hi Jari,

Thanks for the review. We will post a revised version as soon as
possible.

A couple of comments about the process.
The DHC WG so far was not involved upon suggestion of the Mipshop
chairs.
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.

Regards,
Telemaco 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
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,

Process:

>    Section 5
<http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#section-
5>.

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?

>    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

>    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,
>    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
>    [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?

>       [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>] .

>       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

>    [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

> bucket regulator as defined in the MIH specifications [IEEE80221
<http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-IEEE
80221>].
> 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.

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.

>    to.  [RFC3118 <http://tools.ietf.org/html/rfc3118>] provides
mechanisms for both entity authentication and

>    transport connection between two MIHF peers, TLS [RFC4346
<http://tools.ietf.org/html/rfc4346>] SHOULD be
>    follow the recommendations in [RFC4366
<http://tools.ietf.org/html/rfc4366>] that provides generic
>    Alternatively, generic IP layer security, such as IPSec [RFC4301
<http://tools.ietf.org/html/rfc4301>] MAY

Editorial:

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.

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.

Jari

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 19 May 2008 11:16:12 -0400

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

The idea was to not involve the DHC WG in the solution development. DHC
WG review is of course a good thing.

Vijay

> >    In the case where MoS is provided in the home network 
> while the MN
> is
> >       name [RFC2132 <http://tools.ietf.org/html/rfc2132>].  
> A similar
> solution is available for dhcpv6
> >    [RFC3118 <http://tools.ietf.org/html/rfc3118>], where 
> available or
> rely upon link layer security.  This
> >    and responses may cause DoS and the inability of the MN 
> to perform 
> > a

---

From: Jari Arkko <[email-masked]>
Date: Mon, 19 May 2008 19:34:35 +0300

Telemaco,

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

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...

> 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

>>       [RFC2131 <http://tools.ietf.org/html/rfc2131>] that allows
>>     
> Internet devices to obtain IP addresses,
>   
>>    Hence, while in theory MoS can be implemented in different
>>     
> locations,
>   
>>    attachment or after successful IP configuration.  The methodology
>>     
> to
>   
>>    In the case where MoS is provided locally (scenarios S1 and S2) ,
>>     
> the
>   
>>    In the case where MoS is provided in the home network while the MN
>>     
> is
>   
>>       name [RFC2132 <http://tools.ietf.org/html/rfc2132>].  A similar
>>     
>>    Reverse dns query --  When DHCP does not provide the required
>>     
> domain
>   
>>       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
>>     
>>       address of the NAT device, it MUST use that address in the
>>     
> reverse
>   
>>       DNS query.
>>     
>>    attempt to remove portions from the left side of the FQDN and
>>     
> attempt
>   
>>    discover MoS services in home while the MN is in visited network.
>>     
> If
>   
>>    extensions were not identified at the time of writing this
>>     
> document,
>   
>>    If the MN does not yet know the domain name of the network,
>>     
> learning
>   
>>    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
>   
>>    since TCP includes acknowledgement and retransmission
>>     
> functionality.
>>    In the case where DHCP is used for node discovery and
>>     
> authentication
>   
>>    [RFC3118 <http://tools.ietf.org/html/rfc3118>], where available or
>>     
>>    In the case where reliable transport protocol such as TCP is used
>>     
> for
>   
>>    used for message confidentiality and data integrity.  In
>>     
> particular,
>   
>>    for transport connection between two MIHF peers, DTLS [RFC4347
>>     
> <http://tools.ietf.org/html/rfc4347>]
>   
>>    DTLS protocol is based on the Transport Layer Security (TLS)
>>     
> protocol
>

---

From: "Telemaco Melia (tmelia)" <[email-masked]>
Date: Tue, 20 May 2008 17:31:19 +0200

Hi Jari,

Please see below.

-----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,

[tele] We ship them version -05?

[tele] there was not an official email, rather consensus during the
discussion. I will ping Gorry again to recap and formalize that
discussion. As for the comments to your review an email will follow
shortly.

Thanks,
telemaco

Jari

> should be specified. The security mechanisms should be narrowed down 
> to a more reasonable set.
>

> 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 
> 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.
>
> 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?
> 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.

> clear that they are mandatory. From the above I cannot determine what 
> an implementation needs to do.
>   

> 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

> 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?
>

> 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.

> UDP term)
>   
>>    and responses may cause DoS and the inability of the MN to perform

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 May 2008 07:07:35 +0300

Thanks.

Jari

Gorry Fairhurst kirjoitti:
> Jari,
>
> I have not reviewed this document recently. I'll add this to my to-do
> list.
>
> Gorry
>
> Jari Arkko wrote:
>> Telemaco,
>>
>>> written
>>> and
>>> 80221>] . This needs expansion. How does the IEEE scheme affect the
>>> transport
>>> say
>>> node's
>>>> 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.
>>>>     
>>>> 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.
>>>>     
>>> and

---

From: "Telemaco Melia (tmelia)" <[email-masked]>
Date: Wed, 21 May 2008 16:04:11 +0200

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;

Telemaco,

Jari

manner.
would be needed.

network?
draft?

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 20 May 2008 21:34:39 +0200

Jari,

I have not reviewed this document recently. I'll add this to my to-do list.

Gorry

-- 
Dr Gorry Fairhurst, School of Engineering.
The University of Aberdeen is a charity registered in
Scotland No SC013683.
_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop