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

[Jari Arkko <[e-mail]>]

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

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