Re: [Mipshop] WG last call on draft-ietf-mipshop-mis-ps
(cc: 802.21)
I have comment on Section 5.2 from the viewpoint of 802.21 higher
layer transport requirements described in 802.21 draft.
[1]
"
Information from a trusted source: The MN uses the Mobility Service
information to make decisions about what steps to take next. It
is essential that there is some way to ensure that the information
received is from a trustworthy source. This includes cases where
trusted proxies along the path have access to, and may modify,
parts of the Mobility Service information. This requirement
should reuse trust relationships that have already been
established in the network, for example, on the relationships
established by the AAA infrastructure after a mutual
authentication, or on the certificate infrastructure required to
support SEND [9].
"
First of all, is this a requirement on peer entity authentication?
802-21-D04-00 does not have a requirement on end-to-end security where
trusted proxies exist along the path. If the above requirement is
related to end-to-end security, it is beyond 802.21 transport
requirement and I'd recommend that the MIPSHOP draft address
hop-by-hop peer entity authentication only, to narrow down the problem
space. Also, the last sentence seems ambiguous to me. Does it mean
that the security association used for protecting Mobility Service
information should be bootstrapped from network access authentication
or something else?
[2]
"
Congestion Control: A Mobility Service may wish to transfer large
amounts of data, placing a requirement for congestion control in
the transport. There is an interaction between this requirement
and that of the requirement for low latency since ways to deal
with timely delivery of smaller asynchronous messages around the
larger datagrams is required (mitigation of head of line blocking
etc.).
"
802.21 does not have a mandatory requirement on congestion control at
802.21 transport level. Instead, 802.21 has a normative text on
congestion control in section 8.3.1.3 of P802-21-D04-00.
"
Congestion and flow control within the MIH protocol layer is not
needed if it is already provided by the underneath transport
protocol.
For congestion control, a retransmission timer for an MIH message is
computed based on the algorithm defined in IETF RFC 2988. For flow
control, a single rate limiter applies to all traffic (for all
interfaces and message types). It applies to retransmissions, as
well as new messages, although an implementation may choose to
prioritize one over the other. When the rate limiter is in effect,
MIH messages are queued until transmission is re-enabled, or an
error condition may be indicated back to local signaling
applications. The rate limiting mechanism is implementation defined,
but it is recommended that a token bucket limiter as described in
IETF RFC 4443 be used.
"
[3]
"
Secure delivery: The Mobility Service information must be delivered
securely between trusted peers, where the transport may pass
though untrusted intermediate nodes and networks. Design
considerations include whether session based or host based
security associations are required along the chain of NNs, and
what the rate limitation requirements of requests/responses might
be.
"
I think the MIPSHOP draft should be more specific about "secure
delivery". Does it include all of confidentiality, integrity
protection, replay protection and DoS resilience or some of them?
Also, I am not sure what session based and host based security
associations exactly means. Also, this requirement should address
hop-by-hop secure delivery only, since 802-21-D04-00 does not have a
requirement on end-to-end secure delivery. Therefore, "along the
chain of NNs" should be removed. Also, isn't the rate limitation
requirements is part of congestion control requirement rather than
secure delivery requirement?
[4] Let me list 802.21 transport requirements on security described in
Annex D.4 of P802-21-D04-00:
"
SR1.The security mechanism must provide a common security association
(SA) negotiation method regardless of the network location of the MIH
Protocol Entity e.g. on the same subnet, or deep within the network.
SR2.The security mechanism must provide mutual authentication of MIH
end nodes.
SR3.The security mechanism may provide one way authentication of
either of MIH end nodes.
SR4.The security mechanism must provide integrity protection for MIH
Protocol exchanges.
SR5.The security mechanism may provide confidentiality for the MIH
Protocol exchanges.
SR6.The security mechanism must protect against replay attacks.
SR7.The security mechanism may protect MIH service entities and
discovery resources against denial of service attacks.
SR8.The security mechanism must not be dependent on the MIH protocol.
SR9.The security mechanism may provide means to reuse or fast
reestablishment the SA due to host mobility.
"
Specifically, it seems that SR1, SR7, SR8 and SR9 are not covered in
the MIPSHOP draft. SR2 and SR3 may be covered by "Information from a
trusted source" requirement, but it may be good to explicitly mention
SR2 and SR3.
[5] It seems that TR2 of Annex D.4 of P802-21-D04-00 (see below) is
not explicitly covered in the MIPSHOP draft. Support for both IPv4
and IPv6 should be an explicit requirement.
"TR2.The transport protocol must be capable to support both IPv4 and
IPv6 versions."
[6] In Annex D.4 of P802-21-D04-00, there are transport requirements
on NAT and firewall traversal (see below). It seems that those
requirements are missing in the MIPSHOP draft.
"
TR4.The transport protocol must enable Network address Translation
(NAT) traversal for IPv4 networks.
TR5.The transport protocol must enable firewall pass-through for IPv4
and IPv6 networks.
DR4.The discovery protocol must enable Network Address Translator
(NAT) traversal for IPv4 networks.
DR5.The discovery protocol must enable Firewall pass-through for IPv4
and IPv6 networks.
"
Best Regards,
Yoshihiro Ohba