Subject: Re: [Mipshop] WG last call on draft-ietf-mipshop-mis-ps

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 3 Apr 2007 00:15:46 -0400

(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

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 18 Apr 2007 15:11:28 -0700

Hello folks,

The WG last call on draft-ietf-mipshop-mis-ps concluded on April 2nd.
Telemaco has a new version that tries to address the comments received
during the WG last call. The new version should be available soon.

Vijay

Vijay Devarapalli wrote:
> The last call expires on April 2 2007.
> 
> Vijay
> 
> Vijay Devarapalli wrote:
>> Hello,
>>
>> This is a two week working group last call for
>> draft-ietf-mipshop-mis-ps-00.txt. You can find the
>> document at the following URL.
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mis-ps-00.txt
>>
>> The last call expires on March 26 2007.
>>
>> Please post any issues or comments on this document to
>> the MIPSHOP WG mailing list. In case you have reviewed
>> the document and found no issues, please send an email
>> saying you support advancing this document.
>>
>> The intended status for this document is Informational.
>>
>> Vijay
>>