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

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

Responses inline for the parts that need answers:

> Is there a need to state that ES/CS is more likely to be associated with
> a visited network than home?
>
> [TELE] We thought that giving a bit of context on MIH deployment would
> help people not familiar with 802.21. If you believe this is not
> relevant for this document we can shorten the text and just state that
> we do not make any assumption on the location of the MoS (although there
> are some preferred configurations).
>   

OK

>>    The configuration of the MoS could be executed either upon network
>>    attachment or after successful IP configuration.  The methodology
>>     
> to
>   
>>    be used depends on the considered deployment scenario.
>>   
>>     
> First, there's a problem here with what kind of network attachment we
> are talking about. I believe mobility services need to be provided from
> the access network in many situations. IP layer configuration is
> somewhat independent of the link layer attachments, given things like
> bridging, access concentrators, tunneling, proxy MIP and so on. Given
> this, I think the above needs to say that discovery happens upon initial
> or changed link layer attachment.
>
> Secondly, the part about IP configuration needs to talk about changed IP
> configuration as well.  If your DHCP lease expires, and you get a new
> address, will you redo discovery? What if you generate a new 3041
> address? If the prefixes in the RAs change without the routers
> themselves being changed? What if you do DNAv4 or v6 and detect a
> network change?
>
> Thirdly, I do not think it is appropriate to leave this entirely to
> deployments. At least for the mobile node side, code needs to be written
> and every host needs to be able to behave in the correct manner.
>
> In conclusion, this text needs to be written in a much more detailed and
> specification-like manner. It may be that subsequent sections contain at
> least some of these details. If so, forward references would be needed.
>
> [TELE] OK, we will work on it.

Good.

> A comment about location of the MoS:
> there are situations in which it (e.g. IS) may not be provided by the
> visited network.
>   

OK

>>    In the case where MoS is provided locally (scenarios S1 and S2) ,
>>     
> the
>   
>>    discovery techniques described in
>>     
> [I-D.ietf-mipshop-mos-dhcp-options
> <http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-I-D.
> ietf-mipshop-mos-dhcp-options>]
>   
>>    and [I-D.ietf-mipshop-mos-dns-discovery
>>     
> <http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-I-D.
> ietf-mipshop-mos-dns-discovery>] are both applicable and
>   
>>    either one MAY be used to discover the MoS.
>>   
>>     
>
> Dns-discovery requires starting from a known domain name, which seems to
> exclude using it for local networks. Other than as a follow-up to other
> methods, like DHCP.
>
> [TELE] Your question is addressed later in section 5.2. We can modify
> the text by deleting "and either one MAY be used to discover the MoS"
> and adding forward references to section 5.1 and 5.2.
>   

OK

>>    It should be noted that authorization of a MN to use a specific MoS
>>    server is not in scope of this document and is specified in
>>    [IEEE80221
>>     
> <http://tools.ietf.org/html/draft-ietf-mipshop-mstp-solution-04#ref-IEEE
> 80221>] . 
> This needs expansion. How does the IEEE scheme affect the transport
> protocol? Can we end up in a situation where DHCP discovery delivers a
> server address which refuses to talk to us, for instance?
>
> [TELE] Current 802.21 specifications do not address (yet) authorization
> mechanisms. If the Security Study group is formed than it will address
> this issue. In any case, MoS server allocation can be based on policies
> which are independent of the discovery mechanism used by the MN. 
> It is enough to state that while allocation policies are not in scope of
> this document they do not impose requirements on the transport/discovery
> protocol? 
>   

Hmm. I don't think its sufficient.

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

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

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

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

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

Any results of the discussion?

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

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

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

Ok. Any text available yet?

>>    This section assumes the use of IPv6 and DHCPv6 based mechanisms to
>>    discover MoS services in home while the MN is in visited network.
>>     
> If
>   
>>    similar functionalities are desired for IPv4 additional DHCPv4
>>    extensions would be required.  Since use cases requiring these
>>    extensions were not identified at the time of writing this
>>     
> document,
>   
>>    they were excluded from the scope of the document.
>>     
>
> I am surprised by this. Generally speaking, I would expect to see
> feature parity for IPv4 and IPv6 in specifications like this.
>
> [TELE] We had extensive discussions about this and I agree with you. We
> will reflect the changes in the new ID.
>   

Good, thanks.

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

OK.

> Also, its not clear why "pre-configuration is not a feasible solution in
> case of an arbitrary remote network". Surely its no harder to configure
> a given 3rd party network than a given home network. I agree that
> pre-configuration should be avoided if possible, though.
>
> [TELE] We were just arguing that configuring n-times can be an issue,
> especially if 3rd party MoS are deployed in an over the top manner.
>   

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

>> while it is preferred to avoid using MIH ACKs with TCP
>>    since TCP includes acknowledgement and retransmission
>>     
> functionality.
> Is there no need for application level confirmation? TCP ACKs will only
> tell you that the message got through, not, for instance, that it can be
> obeyed.
>
> [TELE] MIH CS messages are always request-response and contain the
> result of the requested operation (e.g. link scan, link switch, etc...).
> ACKs messages in this case are always about message reception
> confirmation. We argue that it is not desirable from a performance point
> of view to implement ACKs both at transport layer (TCP) and at
> application level (MIH). 
>   

OK

>> 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.
>
> [TELE] Currently in IEEE rate limiting mechanism is implementation
> specific and it recommends using RFC 4443. We can refer to RFC 4443 and
> align .21 specs to it. Gorry already commented some figures.
>   

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

>> As [RFC4787 <http://tools.ietf.org/html/rfc4787>] requires a minimum 
>> state timeout of two minutes or more, MIH messages using UDP as 
>> transport SHOULD be sent once every two minutes.
>>     
>
> This is too vague. Sent when? If you have an implementation capable of
> using MIH? When you have something to send, you keep sending it over and
> over again? When you have something to receive you keep sending
> something else? How do you know when you have something to receive, or
> when you want to receive something?
>
> [TELE] Again the signaling method is request-response. The .21 draft
> specifies what messages are expected to be received and when. Here we
> simply argue how an MIH function using UDP + MIH ACKs could deal with
> NAT. 
>   

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

> Note that it would be very unfortunate if every host in every network
> that had turned MIH on would be sending a packet every 2 mins.
>
> [TELE] ES messages are asynchronous and are sent to the network upon
> events happening in the remote stack (MN). Since hosts are mobile and
> wireless conditions can vary quite frequently events can be triggered
> quite often. These parameters are configured in the MIHF. Should we
> reference to it?
> (See Gorry's comment).
>   

Yes you should.

>> MIH messages sent over UDP, TCP or other supported
>>    transport MUST use the default port number defined for that
>>    particular transport.
>>     
> Where are these specified?
>
> [TELE] Section 9 request IANA ports.
>   

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

>> MIH Transport Options
>>     
>
> The document does not talk about how servers know the capabilities of
> clients that send event/command services to. Is this a part of the IEEE
> definitions, and you subscribe to a particular event stream? In any
> case, the document should talk about this and point to the relevant
> other specifications where needed.
>
> [TELE] MIH server capabilities discovery and MIHF registration are part
> of the .21 spec. We can refer to the necessary section if required.
>   

Yes, please do.

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

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

> Also, are TLS and DTLS mandatory to implement?
>
> The explanation on how to use TLS and DTLS seems thin. Is there
> something to be said about what type of certificates or infrastructure
> is needed, what modes of operation are allowed, etc?
>
> [TELE] We will come up with some more concise explanation.   
>   

Ok.

Jari

_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www.ietf.org/mailman/listinfo/mipshop