Nakhjiri Madjid-MNAKHJI1 | 1 Nov 2005 22:23

Bar-meeting on Handover keying design

Hi,

Could you please post this to mipshop mailing list?

Thanks,

Madjid Nakhjiri

Hi,

This is a solicitation for folks interested in a Bar-meeting (Bar pre-BoF or whatever the meeting ends up being) discussing handover keying (I call it HOKEY, and have created a semi-formal proposal in case we end up needing a BOF name for Dallas, who knows it does not hurt to have these things handy :) ). I have a link to an old draft from April down at the bottom of this email, but unfortunately, I did not have time to write a new version of the draft. The old draft may be enough to initiate some discussion. Please let me know if you are interested in participating. We will decide on the "happy hour" time and location :)

I have not yet set up a proper mailing list, so if you are simply interested in checking things out, ***you do not need to send me an email yet*** as I am sending this email to several lists.

If I manage to set of a mailing list in time for IETF, an announcement is to follow.

Regards,

Madjid Nakhjiri

Handover Keying (HOKEY)
================

The recent "AAA Key Management" guidelines as well as several IEEE and WiMAX specification documents attest to the increasing popularity of approach of striving to benefit from the interaction with the authentication (AAA) servers during the network entry to provision further keying materials for support of other networking applications or handovers to other networks.

Recent attempts in applying these methods to access technologies with mobility support (such as WiMAX) has shown that the existing specifications may needs to be further examined or extended from the point of view of handover keying or networking application keying support.

It seems to be more efficient to instead initiate a well-thought and documented design with a first-hand focus on mobility and handover keying and authorization mechanisms. The initial goal of this activity can be to examine the combination of the EAP and AAA documentations to utilize the EAP keying framework and the AAA infrastructure for handover keying and provide an appropriate key hierarchy that can handle the requirements stated in "AAA key management" and further venturing into other network applications that may need keying support.

A background problem statement can be found at

http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt



_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
James Kempf | 2 Nov 2005 16:57

Re: Bar-meeting on Handover keying design

Madjid,
 
I'd be interested in participating.
 
            jak
----- Original Message -----
Sent: Tuesday, November 01, 2005 1:23 PM
Subject: [Mipshop] Bar-meeting on Handover keying design

Hi,

Could you please post this to mipshop mailing list?

Thanks,

Madjid Nakhjiri

Hi,

This is a solicitation for folks interested in a Bar-meeting (Bar pre-BoF or whatever the meeting ends up being) discussing handover keying (I call it HOKEY, and have created a semi-formal proposal in case we end up needing a BOF name for Dallas, who knows it does not hurt to have these things handy :) ). I have a link to an old draft from April down at the bottom of this email, but unfortunately, I did not have time to write a new version of the draft. The old draft may be enough to initiate some discussion. Please let me know if you are interested in participating. We will decide on the "happy hour" time and location :)

I have not yet set up a proper mailing list, so if you are simply interested in checking things out, ***you do not need to send me an email yet*** as I am sending this email to several lists.

If I manage to set of a mailing list in time for IETF, an announcement is to follow.

Regards,

Madjid Nakhjiri

Handover Keying (HOKEY)
================

The recent "AAA Key Management" guidelines as well as several IEEE and WiMAX specification documents attest to the increasing popularity of approach of striving to benefit from the interaction with the authentication (AAA) servers during the network entry to provision further keying materials for support of other networking applications or handovers to other networks.

Recent attempts in applying these methods to access technologies with mobility support (such as WiMAX) has shown that the existing specifications may needs to be further examined or extended from the point of view of handover keying or networking application keying support.

It seems to be more efficient to instead initiate a well-thought and documented design with a first-hand focus on mobility and handover keying and authorization mechanisms. The initial goal of this activity can be to examine the combination of the EAP and AAA documentations to utilize the EAP keying framework and the AAA infrastructure for handover keying and provide an appropriate key hierarchy that can handle the requirements stated in "AAA key management" and further venturing into other network applications that may need keying support.

A background problem statement can be found at

http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt



_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
Moustafa Youssef | 3 Nov 2005 03:40
Picon
Favicon

Final CFP: IEEE Workshop on Dependability and Security in Sensor Networks and Systems

(Our apologies if you receive multiple copies of this CFP)

-------------------------------------------------------------
                   Call for Papers
       Second IEEE Workshop on Dependability and Security in
                    Sensor Networks and Systems
                            (DSSNS'2006)
                        http://www.dssns.org
                        In conjunction with
              2nd NASA/IEEE Systems and Software Week
        30th NASA/IEEE Software Engineering Workshop (SEW'2006)
            Columbia, Maryland, USA ~ April 24-28, 2006

Recently, there has been a growing interest in the potential use
of networked sensors in applications such as smart environments, 
disaster management, combat field reconnaissance, and security 
surveillance. While the initial view of the community was that 
networked sensors will play a complementary role that enhances 
the quality of these applications, recent research results have 
encouraged practitioners to envision an increased reliance on sensor 
networks and systems (SN&S) in such critical and sensitive 
applications. Therefore to realize their potential, necessary 
dependability and security (D&S) measures have to be 
incorporated in the design and during the operation of SN&S. 
Dependability is usually specified using attributes like reliability, 
survivability, safety, maintainability, and availability in presence 
of failure, while security is specified by attributes like integrity, 
authenticity, confidentiality, and availability in presence of 
attacks. D&S services accomplish tasks for attack and
failure prevention, detection and response. The scope of D&S 
services may span the deployed sensors to command nodes 
and likely beyond. It also involves D&S support at, and 
cross-cutting, the protocol stack layers from physical to 
application.

Achieving dependability and security in SN&S will require 
non-conventional mechanisms due to many factors including: 
(1) sensors are significantly constrained in the amount of 
available resources such as energy, storage and computation; 
(2) sensors are expected to be deployed in very large numbers 
in normal as well as harsh/hostile environments; (3) sensor 
networks suffer from structural weakness and limited physical
protection, and (4) localization of impact is complicated due 
to the un-tethered nature of SN&S and of the potential 
attackers. In addition, D&S requirements may vary according
to mission defined over a multi-dimensional context, such 
as field of deployment (e.g., hostile versus friendly), type of 
application (e.g., monitoring, tracking, data collection), mode 
of operation (e.g., normal, exception, post-event recovery), 
and time.

This workshop will foster a forum for discussing and presenting 
recent research results on dependability and security in SN&S. 
Topics of interest include, although not limited to, the following:

- Fault and intrusion-tolerant architectures, middleware and operational
models 
- Robust routing, storage, and processing of sensed data
- D&S architectures, protocols and tools
- Vulnerabilities, attacks and countermeasures
- Monitoring and evaluation techniques
- Robust clustering techniques
- Self-awareness and context-awareness 
- Resilient virtual infrastructures
- Autonomic and adaptive D&S support.
- Formal representation and verification of D&S properties
- Network inference support for D&S
- Quality of service provisioning
- Models, metrics, and measurements for D&S
- Privacy-aware D&S services
- Testbeds, simulation and visualization 
- Agent-based D&S management 
- SN&S support for D&S in larger information grids
- SN&S application development environments

Submission Guidelines
---------------------
Papers should contain original material and not be previously
published, or currently submitted for consideration elsewhere. 
The manuscript should not exceed 20 single-column 
double-space pages in PDF format, font size 11 or larger. 
The first page should include title, authors' contact information, 
abstract and five keywords. 

Please e-mail (subject: DSSNS 2006) the paper as an attachment
in PDF format to: 

submission <at> dssns.org

The e-mail should include title, authors, and the corresponding author's
contact information.

Important Dates
----------------
Submission deadline:	November 7, 2005
Decision notification:	December 20, 2005
Final manuscript due:	January 20, 2006

The accepted papers will appear in a proceedings published by IEEE.
The best paper will be recognized and selected papers will be invited to

a Special Issue of the Journal of Ad Hoc and Sensor Wireless Networks. 

Workshop Co-Chairs
-------------------
Mohamed Eltoweissy
Virginia Tech, USA
E-mail: toweissy <at> vt.edu 

Mohamed Younis
University of Maryland Baltimore County, USA
E-mail: younis <at> csee.umbc.edu 

Publicity Co-Chairs
--------------------
Denis Gracanin
Virginia Tech, USA
E-mail: gracanin <at> vt.edu

Moustafa Youssef
University of Maryland at College Park, USA
E-mail: moustafa <at> cs.umd.edu 

Program Committee
------------------
Farooq Anjum, Telcordia & U. of Penn, USA
David Carman, Johns Hopkins U.– Applied Physics Lab, USA
Ing-Ray Chen, Virginia Tech, USA
M. Nazih Elderini, Alexandria U., Egypt
Deborah Frincke, Pacific Northwest National Lab and U. of Idaho, USA
Ahmed Helmy, University of Southern California, USA
Sushil Jajodia, George Mason U., USA
Shivakant Mishra, U. of Colorado, USA
Peng Ning, North Carolina State U., USA
Cristina Nita-Rotaru, Purdue U., USA
Stephan Olariu, Old Dominion U., USA
David Simplot-Ryl, U. Lille, INRIA Futurs, France
Mani B. Srivastava, U. of California – Los Angeles, USA
John A. Stankovic, U. of Virginia, USA
Ivan Stojmenovic, U. of Ottawa, Canada
Gene Tsudik, U. of California-Irvine, USA
Cliff Wang, Army Research Office, USA
Stephen D. Wolthusen, Fraunhofer-IGD, Germany
Albert Zomaya, U. of Sydney, Australia
Heejin Jang | 3 Nov 2005 06:29

Re: Preliminary Agenda for Vancouver

Hi, Gabriel.

If possible, I'd like to present my draft for FMIPv6 over foo.
(draft-jang-mipshop-fh80216e-00.txt)
Even it is supposed to be presented in 16ng BoF, I think
it's necessary to present it in the mipshop before discussing the new charter item. 

Though the draft is not updated, I'll present including some changes
which would be reflected in next version.
Kindly let me know the result.

Thanks for your efforts.

Regards, 
Heejin.

----- Original Message ----- 
보낸 사람: "gabriel montenegro" <gabriel_montenegro_2000 <at> yahoo.com>
받는 사람: <mipshop <at> ietf.org>; <stefano.faccin <at> nokia.com>
보낸 날짜: 2005년 11월 1일 화요일 오전 5:14
제목: [Mipshop] Preliminary Agenda for Vancouver


> Folks, 
> 
> We have a preliminary agenda for Vancouver, to be found here:
> 
>   http://www3.ietf.org/proceedings/05nov/agenda/mipshop.txt

> 
> The initial state is included below, but for updates, please refer
> to the above site.
> 
> The above is based on received requests, and on mailing list activity.
> If you wish to give a presentation, please send in your request.
> 
> thanks,
> 
> chairs
> 
> ----------------------------------------------------------------
> 64th IETF - Vancouver
> 
> MIPv6 Signaling and Handoff Optimization WG (mipshop)
> 
> MONDAY, November 7, 2005
> 1510-1710 Afternoon Session II
> 1740-1840 Afternoon Session III
> ==================================
> 
> CHAIRS:
> Gabriel Montenegro <gabriel_montenegro_2000 <at> yahoo.com>
> Stefano Faccin <stefano.faccin <at> nokia.com>
> 
> Agenda:
> 
> 
> 1. Preliminaries        5 Mins                 Chairs
>   - Minutes takers
>   - Agenda bashing
> 
> HMIPv6 security
> ------------------
> 
> Topic:     HMIPv6 security
> Presenter: "Suresh Krishnan" <suresh.krishnan <at> ericsson.com>
> Draft:     http://tools.ietf.org/wg/mipshop/draft-haddad-mipshop-hmipv6-security-01.txt

> Length:    10 minutes
> 
>  "The suggested solution is relatively simple and requires using 
>  only the traditional LBU and BA messages between the MN and the MAP."
> 
> 
> Topic:     A Scheme for the Security between Mobile Node  and Mobility Anchor Point in 
>           Hierarchical Mobile IPv6
> Presentor: "Jianying ZHOU" <jyzhou <at> i2r.a-star.edu.sg>
> draft:     http://tools.ietf.org/wg/mipshop/draft-qiu-mipshop-mn-map-security-00.txt

> Time:      15-mins
> 
> TIME:      25 min
> 
> running time: 30min
> 
> FMIPv6
> --------
> topic:     Handover Keys using AAA (including MN-AR Auth Option)
> presentor: "Narayanan Vidya" <vidya <at> motorola.com>
> drafts:   
> http://www.ietf.org/internet-drafts/draft-vidya-mipshop-handover-keys-aaa-01.txt.

>          
> http://www.ietf.org/internet-drafts/draft-narayanan-mipshop-mn-ar-auth-option-00.txt

> Time:      10 mins
> 
>   "The MN-AR Auth Option draft applies to the handover key work and also in
>   general to the 4068bis work. But, it is very short and I don't think it
>   requires separate discussion."
> 
> Topic:     FMIPv6-bis update
> Presentor: Rajeev.Koodli <at> nokia.com
> draft:     http://www.ietf.org/internet-drafts/draft-koodli-mipshop-rfc4068bis-00.txt

> Time:      20 min
> 
> running time: 1 hour
> 
> 802.21
> --------
> Topic:      Problem Statement: Media Independent Handover Signalling
> draft:     
> http://tools.ietf.org/wg/mipshop/draft-hepworth-mipshop-mih-problem-statement-00.txt

> Presentor:  eleanor.hepworth <at> roke.co.uk
> Time:       10 min
> 
> Topic:      Some Requirements for a Handover Information Service
> draft:      http://www.ietf.org/internet-drafts/draft-faccin-mih-infoserv-01.txt 
> Presentor:  Greg.Daley <at> eng.monash.edu.au
> Time:       20 min
> 
> Topic:      A Problem Statement for Event Services and Command Services
>            for Media Independent Handovers.
> Presentor:  TBD
> draft:      http://www.ietf.org/internet-drafts/draft-sreemanthula-es-cs-problem-01.txt

> time:       25 min
> 
> time: 55 min
> 
> running time: 1h55
> 
> FMIPv6 over foo
> -------------------
> topic:     FMIPv6 for 3G CDMA Networks
> presentor: "Hidetoshi Yokota" <yokota <at> kddilabs.jp>
> draft:     http://tools.ietf.org/wg/mipshop/draft-yokota-mipshop-3gfh-01.txt

> time:      10 min.
> 
> running time: 2h05 
> 
> 
> Others: 
> --------
> cga-cba?  fmipv6-over-802.16e?
> 
> 
> WG Directions
> -------------
> Chartering Discussion
> 
> 
> --------------------------------------------------------------------------
> If time remains:
> 
> Misc
> -----
> 
> Topic:     Flush message to prevent packets out-of-sequence in MIPv6 and FMIPv6
> presenter: Jaehwoon Lee (Dongguk University): "jaehwoon" <jaehwoon <at> dongguk.edu>
> draft:     http://www.ietf.org/internet-drafts/draft-jaehwoon-mipshop-flush-mipv6-01.txt

> time:      10 min
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Mipshop mailing list
> Mipshop <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mipshop

> 
>
_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
Nakhjiri Madjid-MNAKHJI1 | 4 Nov 2005 22:51

Hokey mailing list: Bar-meeting on Handover keying design


Folks, the mailing list for handover keying is set up. 
Feel free to subscribe, I am expecting activity after the meeting.
However, the meeting is only tentatively scheduled for Tuesday evening
9-10 PM somewhere in a IETF meeting area to be announce it on the list
or on the wall somewhere. 

The list address is hokey <at> motorola.com, you can send emails but you
cannot see emails if you are not subscribed. To subscribe:

Send a message to "command <at> motorola.com" with the subject
"maillist-subscribe" or "maillist-unsubscribe" depending on what you
wish to do. In the body of the message should be the following. 

listname=HOKEY
subscribers=youremailaddress

Thanks,

Madjid Nakhjiri

-----Original Message-----
From: mip4-bounces <at> ietf.org [mailto:mip4-bounces <at> ietf.org] On Behalf Of
Nakhjiri Madjid-MNAKHJI1
Sent: Tuesday, November 01, 2005 3:25 PM
To: Mobile IPv4 Mailing List
Subject: [Mip4] Bar-meeting on Handover keying design

 
Hi,

This is a solicitation for folks interested in a Bar-meeting (Bar
pre-BoF or whatever the meeting ends up being) discussing handover
keying (I call it HOKEY, and have created a semi-formal proposal in case
we end up needing a BOF name for Dallas, who knows it does not hurt to
have these things handy :) ). I have a link to an old draft from April
down at the bottom of this email, but unfortunately, I did not have time
to write a new version of the draft. The old draft may be enough to
initiate some discussion. Please let me know if you are interested in
participating. We will decide on the "happy hour" time and location :)

I have not yet set up a proper mailing list, so if you are simply
interested in checking things out, ***you do not need to send me an
email yet*** as I am sending this email to several lists.
If I manage to set of a mailing list in time for IETF, an announcement
is to follow.

Regards,

Madjid Nakhjiri

Handover Keying (HOKEY)
================

The recent "AAA Key Management" guidelines as well as several IEEE and
WiMAX specification documents attest to the increasing popularity of
approach of striving to benefit from the interaction with the
authentication (AAA) servers during the network entry to provision
further keying materials for support of other networking applications or
handovers to other networks. 

Recent attempts in applying these methods to access technologies with
mobility support (such as WiMAX) has shown that the existing
specifications may needs to be further examined or extended from the
point of view of handover keying or networking application keying
support.

It seems to be more efficient to instead initiate a well-thought and
documented design with a first-hand focus on mobility and handover
keying and authorization mechanisms. The initial goal of this activity
can be to examine the combination of the EAP and AAA documentations to
utilize the EAP keying framework and the AAA infrastructure for handover
keying and provide an appropriate key hierarchy that can handle the
requirements stated in "AAA key management" and further venturing into
other network applications that may need keying support.

A background problem statement can be found at

http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt

--
Mip4 mailing list: Mip4 <at> ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/
Christian Vogt | 7 Nov 2005 09:28
Picon
Favicon

Weighing the Importance of Proactivity

Hi everybody,

Gabriel asked me to provide some details about the implications of 
proactive CoA registrations (i.e., registrations initiated before L2 
handoff) on RO enhancements such as draft-arkko-mipshop-cga-cba-02.txt [1].

The bottom-line is that the Care-of Test Init and Care-of Keygen Token 
options used in [1] are incompatible with proactive registrations when 
MNs are single-interfaced.  (Things are easier with multiple interfaces.)

This email seeks to solicit comments about the importance of proactive 
registrations when the MN has a single interface only.

Specifically...

[1] replaces the CoTI and CoT messages, which are used in RFC 3775 
during a care-of-address test, with Care-of Test Init and Care-of Keygen 
Token options for the BU and BAck messages.

Our objective for introducing these options was to reduce the number of 
messages required for a correspondent registration.

This is fine when MNs register their CoAs in a reactive way (i.e., after 
L2 handoff), or when MNs have multiple interfaces.

OTOH, separate messages are required when *single*-interfaced MNs want 
to register their CoAs in a *proactive* way (i.e., before L2 handoff). 
In such a case, the handoff procedure might look as follows:

- MN finds a better access point.
- MN obtains prefix information for the link to which that access point 
  belongs (by some external means).
- MN sends an (early) BU + AltCoA option from the old link.
- MN continues to receive and send packets at the old link.
- Arrival of the (early) BAck will cause the mobile node to initiate the 
L2 handoff procedure.
- MN performs a concurrent care-of-address test from the new link.
- MN sends a (full) BU from the new link.

The CN directs packets to the new CoA as of receiving the (early) BU. 
The (early) BAck is the last packet it sends to the old link.

The CN uses Credit-Based Authorization to make use of the AltCoA option 
and the concurrent CoA test secure.

Note:  MNs with multiple interfaces can send the (early) BU and receive 
the (early) BAck on the new link.

The above procedure was already proposed in [2].  But in principle it 
applies to [1] just as well.  I'm currently updating [2] with some more 
details.

We think this issue is worth discussion, so Jari will attend to it 
during his presentation in the Mipshop session.

BTW, the simple solution to this issue would be to go back to the 
original CoTI and CoT messages.

Regards,
- Christian

[1]  http://www.ietf.org/internet-drafts/draft-arkko-mipshop-cga-cba-02.txt
[2] 
http://doc.tm.uka.de/2005/draft-vogt-mobopts-early-binding-updates-00.txt

--

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/
Jari Arkko | 7 Nov 2005 22:50
Picon
Picon

Re: Weighing the Importance of Proactivity

I believe the main difference between the current design
and the one that you outlined is whether the care-of test
runs within the same message or in a separate message.
A separate message, however, does not necessarily mean
additional delay, given that the early BU and the test can
run in parallel.

So one possible design is that the messages are simply
separate; if you are in proactive mode then you delay
the test init until you have actually moved but otherwise
you send it immediately. This adds some some header
overhead, but not a significant amount of delay.

--Jari

Christian Vogt wrote:

> Hi everybody,
>
> Gabriel asked me to provide some details about the implications of 
> proactive CoA registrations (i.e., registrations initiated before L2 
> handoff) on RO enhancements such as draft-arkko-mipshop-cga-cba-02.txt 
> [1].
>
> The bottom-line is that the Care-of Test Init and Care-of Keygen Token 
> options used in [1] are incompatible with proactive registrations when 
> MNs are single-interfaced.  (Things are easier with multiple interfaces.)
>
> This email seeks to solicit comments about the importance of proactive 
> registrations when the MN has a single interface only.
>
> Specifically...
>
> [1] replaces the CoTI and CoT messages, which are used in RFC 3775 
> during a care-of-address test, with Care-of Test Init and Care-of 
> Keygen Token options for the BU and BAck messages.
>
> Our objective for introducing these options was to reduce the number 
> of messages required for a correspondent registration.
>
> This is fine when MNs register their CoAs in a reactive way (i.e., 
> after L2 handoff), or when MNs have multiple interfaces.
>
> OTOH, separate messages are required when *single*-interfaced MNs want 
> to register their CoAs in a *proactive* way (i.e., before L2 handoff). 
> In such a case, the handoff procedure might look as follows:
>
> - MN finds a better access point.
> - MN obtains prefix information for the link to which that access 
> point  belongs (by some external means).
> - MN sends an (early) BU + AltCoA option from the old link.
> - MN continues to receive and send packets at the old link.
> - Arrival of the (early) BAck will cause the mobile node to initiate 
> the L2 handoff procedure.
> - MN performs a concurrent care-of-address test from the new link.
> - MN sends a (full) BU from the new link.
>
> The CN directs packets to the new CoA as of receiving the (early) BU. 
> The (early) BAck is the last packet it sends to the old link.
>
> The CN uses Credit-Based Authorization to make use of the AltCoA 
> option and the concurrent CoA test secure.
>
> Note:  MNs with multiple interfaces can send the (early) BU and 
> receive the (early) BAck on the new link.
>
> The above procedure was already proposed in [2].  But in principle it 
> applies to [1] just as well.  I'm currently updating [2] with some 
> more details.
>
> We think this issue is worth discussion, so Jari will attend to it 
> during his presentation in the Mipshop session.
>
> BTW, the simple solution to this issue would be to go back to the 
> original CoTI and CoT messages.
>
> Regards,
> - Christian
>
>
> [1]  
> http://www.ietf.org/internet-drafts/draft-arkko-mipshop-cga-cba-02.txt
> [2] 
> http://doc.tm.uka.de/2005/draft-vogt-mobopts-early-binding-updates-00.txt
>
Xiaoming Fu | 8 Nov 2005 02:29
Picon

Draft Context transfer using GIST

Hi all,

We have recently written a draft on context transfer using the NSIS GIST 
protocol. It has the following abstract:

    The CXTP specification uses SCTP as transport for CXTP message
    exchanges between a mobile node's new and previous access routers.
    It also relies on a pre-established IPsec ESP transport mode tunnel.
    This document presents an alternative approach based on the NSIS GIST
    protocol, which offers a more flexible transport and richer security
    properties for context transfer between different entities within the
    network that support forwarding of a mobile node's IP traffic.

URL: http://www.ietf.org/internet-drafts/draft-fu-cxtp-gist-00.txt

A prototype implementation of this work is available in
http://user.informatik.uni-goettingen.de/~nsis/release/cxtp/

Your suggestions, comments are very appreciated.

Cheers,
Xiaoming
Christian Vogt | 8 Nov 2005 14:12
Picon
Favicon

Re: Weighing the Importance of Proactivity

Hi Jari.

 > I believe the main difference between the current design
 > and the one that you outlined is whether the care-of test
 > runs within the same message or in a separate message.
 > A separate message, however, does not necessarily mean
 > additional delay, given that the early BU and the test can
 > run in parallel.

Not that there would be any additional delay.  But the signaling 
overhead slightly increases when we use separate messages.

 > So one possible design is that the messages are simply
 > separate; if you are in proactive mode then you delay
 > the test init until you have actually moved but otherwise
 > you send it immediately. This adds some some header
 > overhead, but not a significant amount of delay.

Exactly, my suggestion was to simply use the (separate) CoTI/CoT 
messages specified by RFC 3775.

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

Jari Arkko wrote:
> I believe the main difference between the current design
> and the one that you outlined is whether the care-of test
> runs within the same message or in a separate message.
> A separate message, however, does not necessarily mean
> additional delay, given that the early BU and the test can
> run in parallel.
> 
> So one possible design is that the messages are simply
> separate; if you are in proactive mode then you delay
> the test init until you have actually moved but otherwise
> you send it immediately. This adds some some header
> overhead, but not a significant amount of delay.
> 
> --Jari
> 
> Christian Vogt wrote:
> 
>> Hi everybody,
>>
>> Gabriel asked me to provide some details about the implications of 
>> proactive CoA registrations (i.e., registrations initiated before L2 
>> handoff) on RO enhancements such as draft-arkko-mipshop-cga-cba-02.txt 
>> [1].
>>
>> The bottom-line is that the Care-of Test Init and Care-of Keygen Token 
>> options used in [1] are incompatible with proactive registrations when 
>> MNs are single-interfaced.  (Things are easier with multiple interfaces.)
>>
>> This email seeks to solicit comments about the importance of proactive 
>> registrations when the MN has a single interface only.
>>
>> Specifically...
>>
>> [1] replaces the CoTI and CoT messages, which are used in RFC 3775 
>> during a care-of-address test, with Care-of Test Init and Care-of 
>> Keygen Token options for the BU and BAck messages.
>>
>> Our objective for introducing these options was to reduce the number 
>> of messages required for a correspondent registration.
>>
>> This is fine when MNs register their CoAs in a reactive way (i.e., 
>> after L2 handoff), or when MNs have multiple interfaces.
>>
>> OTOH, separate messages are required when *single*-interfaced MNs want 
>> to register their CoAs in a *proactive* way (i.e., before L2 handoff). 
>> In such a case, the handoff procedure might look as follows:
>>
>> - MN finds a better access point.
>> - MN obtains prefix information for the link to which that access 
>> point  belongs (by some external means).
>> - MN sends an (early) BU + AltCoA option from the old link.
>> - MN continues to receive and send packets at the old link.
>> - Arrival of the (early) BAck will cause the mobile node to initiate 
>> the L2 handoff procedure.
>> - MN performs a concurrent care-of-address test from the new link.
>> - MN sends a (full) BU from the new link.
>>
>> The CN directs packets to the new CoA as of receiving the (early) BU. 
>> The (early) BAck is the last packet it sends to the old link.
>>
>> The CN uses Credit-Based Authorization to make use of the AltCoA 
>> option and the concurrent CoA test secure.
>>
>> Note:  MNs with multiple interfaces can send the (early) BU and 
>> receive the (early) BAck on the new link.
>>
>> The above procedure was already proposed in [2].  But in principle it 
>> applies to [1] just as well.  I'm currently updating [2] with some 
>> more details.
>>
>> We think this issue is worth discussion, so Jari will attend to it 
>> during his presentation in the Mipshop session.
>>
>> BTW, the simple solution to this issue would be to go back to the 
>> original CoTI and CoT messages.
>>
>> Regards,
>> - Christian
>>
>>
>> [1]  
>> http://www.ietf.org/internet-drafts/draft-arkko-mipshop-cga-cba-02.txt
>> [2] 
>> http://doc.tm.uka.de/2005/draft-vogt-mobopts-early-binding-updates-00.txt
Moustafa Youssef | 8 Nov 2005 16:33
Picon
Favicon

DEADLINE EXTENDED: IEEE Workshop on Dependability and Security in Sensor Networks and Systems

Dear Colleagues,
      Due to the large number of requests, the submission 
deadline has been extended to November 14, 2005.

      Please see attached CFP.

Sincerely,
	DSSNS’ 2006 Organization Committee

(Our apologies if you receive multiple copies of this CFP)

-------------------------------------------------------------
                   Call for Papers
       Second IEEE Workshop on Dependability and Security in
                    Sensor Networks and Systems
                            (DSSNS'2006)
                        http://www.dssns.org
                        In conjunction with
              2nd NASA/IEEE Systems and Software Week
        30th NASA/IEEE Software Engineering Workshop (SEW'2006)
            Columbia, Maryland, USA ~ April 24-28, 2006

Recently, there has been a growing interest in the potential use
of networked sensors in applications such as smart environments, 
disaster management, combat field reconnaissance, and security 
surveillance. While the initial view of the community was that 
networked sensors will play a complementary role that enhances 
the quality of these applications, recent research results have 
encouraged practitioners to envision an increased reliance on sensor 
networks and systems (SN&S) in such critical and sensitive 
applications. Therefore to realize their potential, necessary 
dependability and security (D&S) measures have to be 
incorporated in the design and during the operation of SN&S. 
Dependability is usually specified using attributes like reliability, 
survivability, safety, maintainability, and availability in presence 
of failure, while security is specified by attributes like integrity, 
authenticity, confidentiality, and availability in presence of 
attacks. D&S services accomplish tasks for attack and
failure prevention, detection and response. The scope of D&S 
services may span the deployed sensors to command nodes 
and likely beyond. It also involves D&S support at, and 
cross-cutting, the protocol stack layers from physical to 
application.

Achieving dependability and security in SN&S will require 
non-conventional mechanisms due to many factors including: 
(1) sensors are significantly constrained in the amount of 
available resources such as energy, storage and computation; 
(2) sensors are expected to be deployed in very large numbers 
in normal as well as harsh/hostile environments; (3) sensor 
networks suffer from structural weakness and limited physical
protection, and (4) localization of impact is complicated due 
to the un-tethered nature of SN&S and of the potential 
attackers. In addition, D&S requirements may vary according
to mission defined over a multi-dimensional context, such 
as field of deployment (e.g., hostile versus friendly), type of 
application (e.g., monitoring, tracking, data collection), mode 
of operation (e.g., normal, exception, post-event recovery), 
and time.

This workshop will foster a forum for discussing and presenting 
recent research results on dependability and security in SN&S. 
Topics of interest include, although not limited to, the following:

- Fault and intrusion-tolerant architectures, middleware and operational
models 
- Robust routing, storage, and processing of sensed data
- D&S architectures, protocols and tools
- Vulnerabilities, attacks and countermeasures
- Monitoring and evaluation techniques
- Robust clustering techniques
- Self-awareness and context-awareness 
- Resilient virtual infrastructures
- Autonomic and adaptive D&S support.
- Formal representation and verification of D&S properties
- Network inference support for D&S
- Quality of service provisioning
- Models, metrics, and measurements for D&S
- Privacy-aware D&S services
- Testbeds, simulation and visualization 
- Agent-based D&S management 
- SN&S support for D&S in larger information grids
- SN&S application development environments

Submission Guidelines
---------------------
Papers should contain original material and not be previously
published, or currently submitted for consideration elsewhere. 
The manuscript should not exceed 20 single-column 
double-space pages in PDF format, font size 11 or larger. 
The first page should include title, authors' contact information, 
abstract and five keywords. 

Please e-mail (subject: DSSNS 2006) the paper as an attachment
in PDF format to: 

submission <at> dssns.org

The e-mail should include title, authors, and the corresponding author's
contact information.

Important Dates
----------------
Submission deadline:	November 14, 2005
Decision notification:	December 20, 2005
Final manuscript due:	January 20, 2006

The accepted papers will appear in a proceedings published by IEEE.
The best paper will be recognized and selected papers will be invited to

a Special Issue of the Journal of Ad Hoc and Sensor Wireless Networks. 

Workshop Co-Chairs
-------------------
Mohamed Eltoweissy
Virginia Tech, USA
E-mail: toweissy <at> vt.edu 

Mohamed Younis
University of Maryland Baltimore County, USA
E-mail: younis <at> csee.umbc.edu 

Publicity Co-Chairs
--------------------
Denis Gracanin
Virginia Tech, USA
E-mail: gracanin <at> vt.edu

Moustafa Youssef
University of Maryland at College Park, USA
E-mail: moustafa <at> cs.umd.edu 

Program Committee
------------------
Farooq Anjum, Telcordia & U. of Penn, USA
David Carman, Johns Hopkins U.– Applied Physics Lab, USA
Ing-Ray Chen, Virginia Tech, USA
M. Nazih Elderini, Alexandria U., Egypt
Deborah Frincke, Pacific Northwest National Lab and U. of Idaho, USA
Ahmed Helmy, University of Southern California, USA
Sushil Jajodia, George Mason U., USA
Shivakant Mishra, U. of Colorado, USA
Peng Ning, North Carolina State U., USA
Cristina Nita-Rotaru, Purdue U., USA
Stephan Olariu, Old Dominion U., USA
David Simplot-Ryl, U. Lille, INRIA Futurs, France
Mani B. Srivastava, U. of California – Los Angeles, USA
John A. Stankovic, U. of Virginia, USA
Ivan Stojmenovic, U. of Ottawa, Canada
Gene Tsudik, U. of California-Irvine, USA
Cliff Wang, Army Research Office, USA
Stephen D. Wolthusen, Fraunhofer-IGD, Germany
Albert Zomaya, U. of Sydney, Australia

Gmane