Subject: [Mipshop] FW: HEADS-UP>>> MIPSHOP-MIH - Review of draft-ietf-mipshop-mis-ps-04

From: "Stefano Faccin" <[email-masked]>
Date: Tue, 13 Nov 2007 08:54:00 -0800

Hello, a new review of draft-ietf-mipshop-mis-ps has been received.
Thanks Gorry for the review. Please find enclosed the comments
interjected with Jari's comments. 
Stefano
 
> > I have some questions and comments from my reading of:
> > draft-ietf-mipshop-mis-ps-04.
> >
> > None of these relate to problems, but do suggest possibly missing
> > information that could usefully be added to this document.
> >
> > This email can be forwarded to the MIPSHOP-MIH Group. I am sending
it
> > yo you in advance, in case this conflicts with any advice that you
> > have offered.
> >
> > Best wishes,
> >
> > Gorry
> >
> >
------------------------------------------------------------------------
> -
> > 5.1.  Payload Formats and Extensibility Considerations
> >
> >    +----------------+----------------------------------------+
> >    |Mobility Service|           Opaque Payload               |
> >    |Transport Header|     (Mobility Support Service)         |
> >    +----------------+----------------------------------------+
> >
> >                        Figure 5: Protocol Structure
> >
> > I am not sure what this figure shows: Does it imply that only one
> > transport header is applied to each payload.
> 
> I think it shows an assumption that there'd be a transport
> mechanism (e.g., TCP + some MIS specific header), followed
> by opaque payload.
> 
> >
------------------------------------------------------------------------
> -
> > 5.2.  Requirements on the Mobility Service Transport Layer
> >
> >      "Some of the Mobility Services generate time sensitive
> >       information.  Therefore, there is a need to deliver the
> >       information over quite short timescales, and the required
lifetime
> >       of a connection might be quite short lived."
> >
> > This statement is helpful, but not sufficiently detailed to identify
a
> > required transport behaviour. Is anything known about the timeliness
> > of the information, is it nanosecond accuracy, millisecond, some
> > numebr of seconds? - If actual bounds can not be established, can
> > examples be provided of specific cases?
> 
> Right.
> 
> >
------------------------------------------------------------------------
> -
> > Reliability
> >
> >       1.  Assume the transport cannot be guaranteed to support
reliable
> >           delivery.  In this case, the Mobility Support Service
itself
> >           will have to provide a reliability mechanism (at MIH
level) to
> >           allow communicating endpoints to acknowledge receipt of
> >           information.
> >
> > I would expect that such protocol interactions should also be
governed
> > by the guidelines in [3]:
> > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-
> 03.txt
> >
> 
> A statement about this and the reference would be useful in the draft.
> 
> >
------------------------------------------------------------------------
> -
> > Multihoming
> >       ... It is expected that the transport
> >       protocol is capable of receiving information via multiple
links
> >       and to combine information belonging to the same session/
> >       transaction.
> >
> > This could be a transport protocol function, but it may more often
be
> > an application-layer function, integrating messages from different
> > transport protocols. More detail would be useful.
> >
------------------------------------------------------------------------
> -
> >   Information from a trusted source:  The MN uses the Mobilit
> 
> Indeed. This may be related to an AD review comment I had.
> The question is what is transport protocol in this case, is it
> TCP or is it TCP + MIS specific functionality? In the latter case
> some multihoming capabilities could reside in the MIS specific
> part. Or they could be in the application on top. In either
> case, this should be clarified.
> 
> > y 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 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 [10].
> >       Section 7 provides a more complete analysis.
> >
> > I understand this as an authentication requirement. I do not yet
> > understand what the threats are, and how this relates to the
transport
> > service requirement. Would IPsec, TLS, DTLS, be suitable security
> > solutions?
> 
> I think Section 7 is at about the right detail level for this
document,
> and the threats are fairly well described there.
> 
> However, before these guys have done more work on protocol selection,
> its hard to say whether DTLS or IPSec etc would be appropriate.
> 
> Note however that in Section 7 there's a requirement that in some
> cases you only want to authenticate the server, not client. This
> appears to speak against IPsec.
> 
> > Section 7 mentions "tampering, and spoofing", but does not mention
> > replay, is this also an issue?
> 
> Probably. Should be added.
> 
> >
------------------------------------------------------------------------
> -
> >  The requirements do not say anything about data framing. I'm
assuming
> > that this is sending records with a certain record type. Are several
> > records to be sent using the same transport packet or can records be
> > sent back-to-back? If so, how does the receiver identify the
> > boundaries between records?
> 
> Do we need to know? I would assume this depends a little bit
> on what the transport protocol is.
> 
> >
------------------------------------------------------------------------
> -
> > The requirements do not say anything about data integrity - are
there
> > any length and integrity checks applied at the upper (application)
> layer?
> 
> It should. Ok, I'm getting the sense now that Section 7 needs more
> information.
> 
> >
------------------------------------------------------------------------
> -
> > There seems to be at least two types of information, and it is not
> > clear if all types of implementation have the same requirements, and
> > whether a single transport method is expected for all information,
or
> > whether there may be a simultaneous need for more than one type of
> > transport service.
> >
------------------------------------------------------------------------
> -
> > My main concern will be how proposals can be evaluated and compared.
> > While not being a part of the problem statement per se (I guess it
> > could be a valuable appendix), it would seem extremely useful to
have
> > some understanding of some specific examples of use - how large the
> > objects/records are that need to be transported, how frequent
> > transfers may be expected, etc.
> >
> > In previous discussions I encouraged identification of some typical
> > transport "user" requirements:
> >     - What are the minimum, maximum, typical sizes of message?
> >     - What is the assumed Path MTU?
> >     - What are the message exchanges they envisage?
> >     - How timely is this information? (delivery in 30 ms or 30
seconds?
------------------------------------------------------------------------
> -
> This would be very helpful, yes.
> 
> Again, thanks for your review.
> 
> Jari
> 

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