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

["Vijay Devarapalli" <[e-mail]>]

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

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

Vijay

> 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Jari Arkko
> Sent: Monday, May 19, 2008 2:21 PM
> To: [e-mail]; 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:
> 
> >    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-0
> 4#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-0
> 4#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-0
> 4#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-0
> 4#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-0
> 4#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-0
> 4#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?
> 
> > 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-0
> 4#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-0
> 4#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-0
> 4#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-0
> 4#ref-IEEE
> 80221>].
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mipshop
> _______________________________________________
> Mipshop mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mipshop
> 
_______________________________________________
Mipshop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mipshop