List Info

Thread: MSEC meeting summary for group review




MSEC meeting summary for group review
user name
2006-11-09 20:42:43
Folks,

Below is the meeting summary I am presenting, please send
any revisions.

+++++++
MSEC discussed several current deliverables and oddly enough
for a 
group that is on its last leg, several new proposals.  It
appears 
that some of the proposals are extensions to existing
protocols/RFCs, 
which are generally ok; we need to get them
documented/published for 
interoperability purposes.  There are however some proposals
with new 
goals, e.g., OSPFv3 security, specifically, key management
extensions 
to support OSPFv3.  That is out of scope of our charter.

That brings us to cross-area work that I reported here at
SAAG 
before: RMT and IPDVB security requirements are two
examples.  So, if 
the OSPF WG wants MSEC to do some work, we can discuss it. 
I will 
start a conversation with the OSPF WG chairs and go from
there.

Another work item that has come up is how to do CTR mode in
the 
multi-sender case.  Our charter says "Initial efforts
will focus on 
scalable solutions for groups with a single source and a
very large 
number of recipients" but does not explicitly rule out
the 
multi-sender case.  Perhaps we can take up that item,
although I am 
apprehensive about doing that work piece-meal.

Folks are encouraged to finalize proposals for new work
before the 
Prague meeting and finalize all work before the Chicago
meeting.
+++++++++

Lakshminath


_______________________________________________
MSEC mailing list
MSECietf.org
https://w
ww1.ietf.org/mailman/listinfo/msec
MSEC meeting summary for group review
user name
2006-11-10 15:29:08
Lakshminath,
   I'd like to know if people think we make GDOI-SRTP a WG
item.

thanks, Mark
On Nov 9, 2006, at 12:42 PM, Lakshminath Dondeti wrote:

> Folks,
>
> Below is the meeting summary I am presenting, please
send any  
> revisions.
>
> +++++++
> MSEC discussed several current deliverables and oddly
enough for a  
> group that is on its last leg, several new proposals. 
It appears  
> that some of the proposals are extensions to existing
protocols/ 
> RFCs, which are generally ok; we need to get them
documented/ 
> published for interoperability purposes.  There are
however some  
> proposals with new goals, e.g., OSPFv3 security,
specifically, key  
> management extensions to support OSPFv3.  That is out
of scope of  
> our charter.
>
> That brings us to cross-area work that I reported here
at SAAG  
> before: RMT and IPDVB security requirements are two
examples.  So,  
> if the OSPF WG wants MSEC to do some work, we can
discuss it.  I  
> will start a conversation with the OSPF WG chairs and
go from there.
>
> Another work item that has come up is how to do CTR
mode in the  
> multi-sender case.  Our charter says "Initial
efforts will focus on  
> scalable solutions for groups with a single source and
a very large  
> number of recipients" but does not explicitly rule
out the multi- 
> sender case.  Perhaps we can take up that item,
although I am  
> apprehensive about doing that work piece-meal.
>
> Folks are encouraged to finalize proposals for new work
before the  
> Prague meeting and finalize all work before the Chicago
meeting.
> +++++++++
>
> Lakshminath
>
>
> _______________________________________________
> MSEC mailing list
> MSECietf.org
> https://w
ww1.ietf.org/mailman/listinfo/msec

_______________________________________________
MSEC mailing list
MSECietf.org
https://w
ww1.ietf.org/mailman/listinfo/msec
MSEC meeting summary for group review
user name
2006-11-11 02:23:08
Hi all,

Existing MSEC protocols are not fully competent for group
keying of some important
scenarios such as OSPFv3, PIM-SM, etc. Extensions need to be
made. In OSPFv3 scenario, for
example, IP multicast is not always deployed. So, reliable
rekeying can not always be
achieved by RMT mechanisms. Routes may be shortly
disconnected because of OSPFv3 routers'
rebooting or other troubles. So it can not be assumed that
an OSPFv3 can always receive
the rekeying messages pushed by GCKS when some MSEC
protocols is used in this scenario.
There may be other new requirements to be proposed. I
strongly propose the work of
extending MSEC protocols as a working group item.

Regards,
Liu Ya 

On November 10, 2006 4:43 AM, Lakshminath wrote:
> 
> Folks,
> 
> Below is the meeting summary I am presenting, please
send any 
> revisions.
> 
> +++++++
> MSEC discussed several current deliverables and oddly
enough 
> for a group that is on its last leg, several new
proposals.  
> It appears that some of the proposals are extensions to

> existing protocols/RFCs, which are generally ok; we
need to 
> get them documented/published for interoperability
purposes.  
> There are however some proposals with new goals, e.g.,
OSPFv3 
> security, specifically, key management extensions to
support 
> OSPFv3.  That is out of scope of our charter.
> 
> That brings us to cross-area work that I reported here
at SAAG
> before: RMT and IPDVB security requirements are two
examples. 
>  So, if the OSPF WG wants MSEC to do some work, we can 
> discuss it.  I will start a conversation with the OSPF
WG 
> chairs and go from there.
> 
> Another work item that has come up is how to do CTR
mode in 
> the multi-sender case.  Our charter says "Initial
efforts 
> will focus on scalable solutions for groups with a
single 
> source and a very large number of recipients" but
does not 
> explicitly rule out the multi-sender case.  Perhaps we
can 
> take up that item, although I am apprehensive about
doing 
> that work piece-meal.
> 
> Folks are encouraged to finalize proposals for new work

> before the Prague meeting and finalize all work before
the 
> Chicago meeting.
> +++++++++
> 
> Lakshminath
> 
> 
> _______________________________________________
> MSEC mailing list
> MSECietf.org
> https://w
ww1.ietf.org/mailman/listinfo/msec
> 



_______________________________________________
MSEC mailing list
MSECietf.org
https://w
ww1.ietf.org/mailman/listinfo/msec
[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )