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

[Gorry Fairhurst <[e-mail]>]

Jari,

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

Gorry

Jari Arkko wrote:
> 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
> 
>> 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-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-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-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-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
>>
>>
>>   
> 
> 

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