[MIPSHOP-MIH-DT] [Fwd: secdir review of draft-ietf-mipshop-mis-ps-05]

Vijay Devarapalli <vijay.devarapalli@azairenet.com> Wed, 19 December 2007 19:05 UTC

Return-path: <mipshop-mih-dt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54EN-0004KF-0g; Wed, 19 Dec 2007 14:05:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J54EK-0004JU-Vp for mipshop-mih-dt@ietf.org; Wed, 19 Dec 2007 14:05:20 -0500
Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J54EI-0004wE-5q for mipshop-mih-dt@ietf.org; Wed, 19 Dec 2007 14:05:20 -0500
Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Dec 2007 11:05:17 -0800
Message-ID: <47696B6D.6090507@azairenet.com>
Date: Wed, 19 Dec 2007 11:05:17 -0800
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "mipshop-mih-dt@ietf.org" <mipshop-mih-dt@ietf.org>, telemaco.melia@googlemail.com
Content-Type: multipart/mixed; boundary="------------090402020005010701070209"
X-OriginalArrivalTime: 19 Dec 2007 19:05:17.0489 (UTC) FILETIME=[17E8B210:01C84272]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34793307b79a1353c9d03ed8a398bb86
Cc:
Subject: [MIPSHOP-MIH-DT] [Fwd: secdir review of draft-ietf-mipshop-mis-ps-05]
X-BeenThere: mipshop-mih-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MIPSHOP Media Independent Handover Design Team List <mipshop-mih-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www1.ietf.org/mailman/private/mipshop-mih-dt>
List-Post: <mailto:mipshop-mih-dt@ietf.org>
List-Help: <mailto:mipshop-mih-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=subscribe>
Errors-To: mipshop-mih-dt-bounces@ietf.org

FYI.

There are a few text changes required.

Vijay
--- Begin Message ---
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Security:

In Section 5.2, there is an item titled "Security association
management" which does not specify which parties the security
associations are to be between.  I assume they are to be between
endpoints exchanging Mobility Services information.

Section 5.2, under "Secure delivery", mentions guarding against replay
attacks.  This can be challenging in a connectionless protocol.

Section 7, "Security Considerations", mentions the importance of
protecting or concealing information identifying a mobile node because
a mobile device is frequently associated exclusively with one user.
How well must this identify information be protected from nodes on the
same link which can examine traffic on that link?  Does this protected
identify information include link layer addresses?  My understanding
is that many link layer addresses are fixed in hardware and exposed in
the link layer protocol.  It may be that link layer addresses need not
be protected on the link layer beyond whatever (lack of?) protection
already in place at the link layer, but need only be protected at
higher layers.

References:

I found that my institutional IEEE subscription did not give me access
to IEEE draft standards.  Also, IEEE Xplore only lists a citation for
P802.21/D7.1 (August 2007), rather than P802.21/D7.0 (July 2007) as
cited in the References section.  It may be that D7.0 was obsoleted by
the August document.

Terminology:

Is a Mobile Node a distinct concept from a Network Node?  Some of the
usage in Section 4 implies that a Network Node is a fixed-position
element of a network and is not mobile.

Other:

In Section 5, mention is made of a "Mobility Services Transport Layer"
without specifying whether the transport is connection-oriented,
connectionless, or potentially both; however, the mention in Section
5.1 of fragmentation and reassembly might imply a connectionless
transport.

Section 5.1 is titled "Payload Formats and Extensibility
Considerations" but contains no direct mention of extensibility.

The Appendix reproduces an informative section of the IEEE 802.21
draft standard listing requirements placed on L3 transport by IEEE
802.21, but I do not see any text elsewhere in this I-D setting forth
the correspondences between the 802.21 requirements and the proposals
or requirements of this I-D.  It may be useful to indicate those
correspondences, but I can also see arguments for why it is not
necessary to do so.
--- End Message ---
--- Begin Message ---
Tom,

Thanks for your review! A few observations inline:

> In Section 5.2, there is an item titled "Security association
> management" which does not specify which parties the security
> associations are to be between.  I assume they are to be between
> endpoints exchanging Mobility Services information.
>   

Yes. It would be useful add clarifying text. I have added the following
RFC Editor note:

OLD:
 A common security association negotiation method, independent
 of any specific MSTP user, should be implemented.
NEW:
 A common security association negotiation method, independent
 of any specific MSTP user, should be implemented between the endpoints
 of the MSTP.


> Section 5.2, under "Secure delivery", mentions guarding against replay
> attacks.  This can be challenging in a connectionless protocol.
>   

Yes. Elsewhere in Section 5.2 it is already mentioned that the low
latency, connectionless delivery requirements may interact with other
requirements.

> Section 7, "Security Considerations", mentions the importance of
> protecting or concealing information identifying a mobile node because
> a mobile device is frequently associated exclusively with one user.
> How well must this identify information be protected from nodes on the
> same link which can examine traffic on that link?  Does this protected
> identify information include link layer addresses?  My understanding
> is that many link layer addresses are fixed in hardware and exposed in
> the link layer protocol.  It may be that link layer addresses need not
> be protected on the link layer beyond whatever (lack of?) protection
> already in place at the link layer, but need only be protected at
> higher layers.
>   

This document is only about the implications of the MSTP; we do know
that there are other issues, but they should be topic of other
documents. Link layer addresses and privacy is one such issue.

> References:
>
> I found that my institutional IEEE subscription did not give me access
> to IEEE draft standards.  Also, IEEE Xplore only lists a citation for
> P802.21/D7.1 (August 2007), rather than P802.21/D7.0 (July 2007) as
> cited in the References section.  It may be that D7.0 was obsoleted by
> the August document.
>   

I believe we have IETF access to the documents in question, just ask the
WG chairs.

> Terminology:
>
> Is a Mobile Node a distinct concept from a Network Node?  Some of the
> usage in Section 4 implies that a Network Node is a fixed-position
> element of a network and is not mobile.
>   

Yes. Mobile node is the one moving around, and talking to the network
nodes to get MIS information.

> Other:
>
> In Section 5, mention is made of a "Mobility Services Transport Layer"
> without specifying whether the transport is connection-oriented,
> connectionless, or potentially both; however, the mention in Section
> 5.1 of fragmentation and reassembly might imply a connectionless
> transport.
>   

My understanding is that this is left intentionally vague; just the
requirements on what the transport layer needs to achieve are listed.

> Section 5.1 is titled "Payload Formats and Extensibility
> Considerations" but contains no direct mention of extensibility.
>   

I think the idea is that the opaque payload allows various types of
information to be passed, without changing the transport protocol.

> The Appendix reproduces an informative section of the IEEE 802.21
> draft standard listing requirements placed on L3 transport by IEEE
> 802.21, but I do not see any text elsewhere in this I-D setting forth
> the correspondences between the 802.21 requirements and the proposals
> or requirements of this I-D.  It may be useful to indicate those
> correspondences, but I can also see arguments for why it is not
> necessary to do so.
>   
Yes, this would be useful. Authors, chairs? If you have text, I could
place it to the tracker.

Jari


--- End Message ---
--- Begin Message ---
I think it would be good for the authors of this document to review
the exchange surrounding the location privacy statement in mip6 and to
make sure that their scope survives the same examination.

--- End Message ---
--- Begin Message ---
Discuss:
The comments below are based partially on OPS-DIR review by Scott Bradner. 

The inclusion in Appendix of requirements from a work-in-progress document of another SDO seems a bad idea. In IEEE a Draft is the equivalent of an IETF Internet-Draft, and the usage of the term Draft Standard in this document may be mis-leading. I suggest that either the approval of this document is delayed until the IEEE 802.21 specification is approved in the IEEE, or that the appendix makes clear what is the status of the document in the IEEE.

Comment:
1. The document does not offer any discussion or guidance of the operational aspects of implementing a mobility services transport. For example many subsections of section 5.2 could raise significant operational concerns but such concerns are not addressed in the draft.

2. The document has too many authors (more than the rules permit)

3. sec 4.2 - the draft  suggests that a layer 2 protocol could be used as mobility transport for part or all of a path - it seems that adding another L2 protocol to a network could raise a number of serious operational issues - e.g, how to ensure that it is properly filtered to limit the impact of a rogue device

4. sec 5.2 - low latency - the draft says: "It is expected that Events and Commands messages arrive at a rate of hundreds of milliseconds in order to capture quick changes in the environment and/ or process handover commands."

"a rate of hundreds of milliseconds" does not make sense

5. both the "Congestion Control" and "Fragmentation and reassembly"
sections do not strongly say that use of an IETF-approved congestion control protocol is required and that fragmentation should not happen - violation of these requirements could cause congestion

6. sec 7 - security considerations this section says that the device should not have to identify itself in order to get some types of information - I expect that most network operators would want to insist on knowing what mobile devices are on their network

7. section 11.1 - rfc 2119 should not be used in a document of this type and, even if it were, the reference to rfc 2119 is informative not normative

--- End Message ---
--- Begin Message ---
I'm certainly willing to consider changing the wording to make the
status of the other requirements clearer, or even axing the entire
appendix. Authors?

Jari

Dan Romascanu kirjoitti:
> Discuss:
> The comments below are based partially on OPS-DIR review by Scott Bradner. 
>
> The inclusion in Appendix of requirements from a work-in-progress document of another SDO seems a bad idea. In IEEE a Draft is the equivalent of an IETF Internet-Draft, and the usage of the term Draft Standard in this document may be mis-leading. I suggest that either the approval of this document is delayed until the IEEE 802.21 specification is approved in the IEEE, or that the appendix makes clear what is the status of the document in the IEEE.
>
> Comment:
> 1. The document does not offer any discussion or guidance of the operational aspects of implementing a mobility services transport. For example many subsections of section 5.2 could raise significant operational concerns but such concerns are not addressed in the draft.
>
> 2. The document has too many authors (more than the rules permit)
>
> 3. sec 4.2 - the draft  suggests that a layer 2 protocol could be used as mobility transport for part or all of a path - it seems that adding another L2 protocol to a network could raise a number of serious operational issues - e.g, how to ensure that it is properly filtered to limit the impact of a rogue device
>
> 4. sec 5.2 - low latency - the draft says: "It is expected that Events and Commands messages arrive at a rate of hundreds of milliseconds in order to capture quick changes in the environment and/ or process handover commands."
>
> "a rate of hundreds of milliseconds" does not make sense
>
> 5. both the "Congestion Control" and "Fragmentation and reassembly"
> sections do not strongly say that use of an IETF-approved congestion control protocol is required and that fragmentation should not happen - violation of these requirements could cause congestion
>
> 6. sec 7 - security considerations this section says that the device should not have to identify itself in order to get some types of information - I expect that most network operators would want to insist on knowing what mobile devices are on their network
>
> 7. section 11.1 - rfc 2119 should not be used in a document of this type and, even if it were, the reference to rfc 2119 is informative not normative
>
>
>
>
>
>   

--- End Message ---
--- Begin Message ---
I suggest removing the annex and adding the following sentence in
Section 1:

"
Requirements to support 802.21 by L3 and above transport are described
in [1].
"

Yoshihiro Ohba


On Wed, Dec 19, 2007 at 05:34:56PM +0200, Jari Arkko wrote:
> I'm certainly willing to consider changing the wording to make the
> status of the other requirements clearer, or even axing the entire
> appendix. Authors?
> 
> Jari
> 
> Dan Romascanu kirjoitti:
> > Discuss:
> > The comments below are based partially on OPS-DIR review by Scott Bradner. 
> >
> > The inclusion in Appendix of requirements from a work-in-progress document of another SDO seems a bad idea. In IEEE a Draft is the equivalent of an IETF Internet-Draft, and the usage of the term Draft Standard in this document may be mis-leading. I suggest that either the approval of this document is delayed until the IEEE 802.21 specification is approved in the IEEE, or that the appendix makes clear what is the status of the document in the IEEE.
> >
> > Comment:
> > 1. The document does not offer any discussion or guidance of the operational aspects of implementing a mobility services transport. For example many subsections of section 5.2 could raise significant operational concerns but such concerns are not addressed in the draft.
> >
> > 2. The document has too many authors (more than the rules permit)
> >
> > 3. sec 4.2 - the draft  suggests that a layer 2 protocol could be used as mobility transport for part or all of a path - it seems that adding another L2 protocol to a network could raise a number of serious operational issues - e.g, how to ensure that it is properly filtered to limit the impact of a rogue device
> >
> > 4. sec 5.2 - low latency - the draft says: "It is expected that Events and Commands messages arrive at a rate of hundreds of milliseconds in order to capture quick changes in the environment and/ or process handover commands."
> >
> > "a rate of hundreds of milliseconds" does not make sense
> >
> > 5. both the "Congestion Control" and "Fragmentation and reassembly"
> > sections do not strongly say that use of an IETF-approved congestion control protocol is required and that fragmentation should not happen - violation of these requirements could cause congestion
> >
> > 6. sec 7 - security considerations this section says that the device should not have to identify itself in order to get some types of information - I expect that most network operators would want to insist on knowing what mobile devices are on their network
> >
> > 7. section 11.1 - rfc 2119 should not be used in a document of this type and, even if it were, the reference to rfc 2119 is informative not normative
> >
> >
> >
> >
> >
> >   
> 
> 
> 
--- End Message ---
--- Begin Message ---
Yoshihiro Ohba wrote:
> I suggest removing the annex and adding the following sentence in
> Section 1:
> 
> "
> Requirements to support 802.21 by L3 and above transport are described
> in [1].
> "

Agree.

Vijay

> 
> Yoshihiro Ohba
> 
> 
> On Wed, Dec 19, 2007 at 05:34:56PM +0200, Jari Arkko wrote:
>> I'm certainly willing to consider changing the wording to make the
>> status of the other requirements clearer, or even axing the entire
>> appendix. Authors?
>>
>> Jari
>>
>> Dan Romascanu kirjoitti:
>>> Discuss:
>>> The comments below are based partially on OPS-DIR review by Scott Bradner. 
>>>
>>> The inclusion in Appendix of requirements from a work-in-progress document of another SDO seems a bad idea. In IEEE a Draft is the equivalent of an IETF Internet-Draft, and the usage of the term Draft Standard in this document may be mis-leading. I suggest that either the approval of this document is delayed until the IEEE 802.21 specification is approved in the IEEE, or that the appendix makes clear what is the status of the document in the IEEE.
>>>
>>> Comment:
>>> 1. The document does not offer any discussion or guidance of the operational aspects of implementing a mobility services transport. For example many subsections of section 5.2 could raise significant operational concerns but such concerns are not addressed in the draft.
>>>
>>> 2. The document has too many authors (more than the rules permit)
>>>
>>> 3. sec 4.2 - the draft  suggests that a layer 2 protocol could be used as mobility transport for part or all of a path - it seems that adding another L2 protocol to a network could raise a number of serious operational issues - e.g, how to ensure that it is properly filtered to limit the impact of a rogue device
>>>
>>> 4. sec 5.2 - low latency - the draft says: "It is expected that Events and Commands messages arrive at a rate of hundreds of milliseconds in order to capture quick changes in the environment and/ or process handover commands."
>>>
>>> "a rate of hundreds of milliseconds" does not make sense
>>>
>>> 5. both the "Congestion Control" and "Fragmentation and reassembly"
>>> sections do not strongly say that use of an IETF-approved congestion control protocol is required and that fragmentation should not happen - violation of these requirements could cause congestion
>>>
>>> 6. sec 7 - security considerations this section says that the device should not have to identify itself in order to get some types of information - I expect that most network operators would want to insist on knowing what mobile devices are on their network
>>>
>>> 7. section 11.1 - rfc 2119 should not be used in a document of this type and, even if it were, the reference to rfc 2119 is informative not normative
>>>
>>>
>>>
>>>
>>>
>>>   
>>
>>

--- End Message ---
--- Begin Message ---
FYI, Dan, I placed this in the tracker as an RFC Editor note.

Jari

Vijay Devarapalli kirjoitti:
> Yoshihiro Ohba wrote:
>   
>> I suggest removing the annex and adding the following sentence in
>> Section 1:
>>
>> "
>> Requirements to support 802.21 by L3 and above transport are described
>> in [1].
>> "
>>     
>
> Agree.
>
> Vijay
>
>   
>> Yoshihiro Ohba
>>
>>
>> On Wed, Dec 19, 2007 at 05:34:56PM +0200, Jari Arkko wrote:
>>     
>>> I'm certainly willing to consider changing the wording to make the
>>> status of the other requirements clearer, or even axing the entire
>>> appendix. Authors?
>>>
>>> Jari
>>>
>>> Dan Romascanu kirjoitti:
>>>       
>>>> Discuss:
>>>> The comments below are based partially on OPS-DIR review by Scott Bradner. 
>>>>
>>>> The inclusion in Appendix of requirements from a work-in-progress document of another SDO seems a bad idea. In IEEE a Draft is the equivalent of an IETF Internet-Draft, and the usage of the term Draft Standard in this document may be mis-leading. I suggest that either the approval of this document is delayed until the IEEE 802.21 specification is approved in the IEEE, or that the appendix makes clear what is the status of the document in the IEEE.
>>>>
>>>> Comment:
>>>> 1. The document does not offer any discussion or guidance of the operational aspects of implementing a mobility services transport. For example many subsections of section 5.2 could raise significant operational concerns but such concerns are not addressed in the draft.
>>>>
>>>> 2. The document has too many authors (more than the rules permit)
>>>>
>>>> 3. sec 4.2 - the draft  suggests that a layer 2 protocol could be used as mobility transport for part or all of a path - it seems that adding another L2 protocol to a network could raise a number of serious operational issues - e.g, how to ensure that it is properly filtered to limit the impact of a rogue device
>>>>
>>>> 4. sec 5.2 - low latency - the draft says: "It is expected that Events and Commands messages arrive at a rate of hundreds of milliseconds in order to capture quick changes in the environment and/ or process handover commands."
>>>>
>>>> "a rate of hundreds of milliseconds" does not make sense
>>>>
>>>> 5. both the "Congestion Control" and "Fragmentation and reassembly"
>>>> sections do not strongly say that use of an IETF-approved congestion control protocol is required and that fragmentation should not happen - violation of these requirements could cause congestion
>>>>
>>>> 6. sec 7 - security considerations this section says that the device should not have to identify itself in order to get some types of information - I expect that most network operators would want to insist on knowing what mobile devices are on their network
>>>>
>>>> 7. section 11.1 - rfc 2119 should not be used in a document of this type and, even if it were, the reference to rfc 2119 is informative not normative
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>   
>>>>         
>>>       
>
>
>
>   

--- End Message ---
--- Begin Message ---
It would be good is reference [1] would also be marked as
'work-in-progress'. Of course, if by the time of the publication of the
RFC the IEEE 802.21 has already approved the standard, this can be
dropped. 

Dan


 
 

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net] 
> Sent: Wednesday, December 19, 2007 7:50 PM
> To: Vijay Devarapalli
> Cc: Romascanu, Dan (Dan); Yoshihiro Ohba; 
> mipshop-chairs@tools.ietf.org; iesg@ietf.org; 
> draft-ietf-mipshop-mis-ps@tools.ietf.org
> Subject: Re: DISCUSS and COMMENT: draft-ietf-mipshop-mis-ps
> 
> FYI, Dan, I placed this in the tracker as an RFC Editor note.
> 
> Jari
> 
> Vijay Devarapalli kirjoitti:
> > Yoshihiro Ohba wrote:
> >   
> >> I suggest removing the annex and adding the following sentence in 
> >> Section 1:
> >>
> >> "
> >> Requirements to support 802.21 by L3 and above transport are 
> >> described in [1].
> >> "
> >>     
> >
> > Agree.
> >
> > Vijay
> >
> >   
> >> Yoshihiro Ohba
> >>
> >>
> >> On Wed, Dec 19, 2007 at 05:34:56PM +0200, Jari Arkko wrote:
> >>     
> >>> I'm certainly willing to consider changing the wording to 
> make the 
> >>> status of the other requirements clearer, or even axing 
> the entire 
> >>> appendix. Authors?
> >>>
> >>> Jari
> >>>
> >>> Dan Romascanu kirjoitti:
> >>>       
> >>>> Discuss:
> >>>> The comments below are based partially on OPS-DIR review 
> by Scott Bradner. 
> >>>>
> >>>> The inclusion in Appendix of requirements from a 
> work-in-progress document of another SDO seems a bad idea. In 
> IEEE a Draft is the equivalent of an IETF Internet-Draft, and 
> the usage of the term Draft Standard in this document may be 
> mis-leading. I suggest that either the approval of this 
> document is delayed until the IEEE 802.21 specification is 
> approved in the IEEE, or that the appendix makes clear what 
> is the status of the document in the IEEE.
> >>>>
> >>>> Comment:
> >>>> 1. The document does not offer any discussion or 
> guidance of the operational aspects of implementing a 
> mobility services transport. For example many subsections of 
> section 5.2 could raise significant operational concerns but 
> such concerns are not addressed in the draft.
> >>>>
> >>>> 2. The document has too many authors (more than the rules permit)
> >>>>
> >>>> 3. sec 4.2 - the draft  suggests that a layer 2 protocol 
> could be 
> >>>> used as mobility transport for part or all of a path - it seems 
> >>>> that adding another L2 protocol to a network could raise 
> a number 
> >>>> of serious operational issues - e.g, how to ensure that it is 
> >>>> properly filtered to limit the impact of a rogue device
> >>>>
> >>>> 4. sec 5.2 - low latency - the draft says: "It is 
> expected that Events and Commands messages arrive at a rate 
> of hundreds of milliseconds in order to capture quick changes 
> in the environment and/ or process handover commands."
> >>>>
> >>>> "a rate of hundreds of milliseconds" does not make sense
> >>>>
> >>>> 5. both the "Congestion Control" and "Fragmentation and 
> reassembly"
> >>>> sections do not strongly say that use of an IETF-approved 
> >>>> congestion control protocol is required and that fragmentation 
> >>>> should not happen - violation of these requirements could cause 
> >>>> congestion
> >>>>
> >>>> 6. sec 7 - security considerations this section says that the 
> >>>> device should not have to identify itself in order to get some 
> >>>> types of information - I expect that most network 
> operators would 
> >>>> want to insist on knowing what mobile devices are on 
> their network
> >>>>
> >>>> 7. section 11.1 - rfc 2119 should not be used in a 
> document of this 
> >>>> type and, even if it were, the reference to rfc 2119 is 
> informative 
> >>>> not normative
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>   
> >>>>         
> >>>       
> >
> >
> >
> >   
> 
> 
--- End Message ---
_______________________________________________
MIPSHOP-MIH-DT mailing list
MIPSHOP-MIH-DT@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt