Subject: Re: [MSEC] GSAKMP issue 00: IANA considerations

From: Uri Meth <[email-masked]>
Date: Sun, 7 Sep 2003 12:21:32 -0400

Reposting, as my first attempts did not seem to make it to the list.

Sorry for jumping into these discussions so late, but I just getting
caught up after being away for over 3 weeks.

George,

From what you write that the spec points to IKE as a template, I think
you meant to say ISAKMP.  GSAKMP is similar to ISAKMP in that is uses
the same payload chaining concept as GSAKMP mentions in section 3.2.1.
GSAKMP does not use IKE as a template.

WRT registering values with IANA, we will be looking into this, good
catch.  We will follow examples from other specs to fill this need.

UM

On Sat, Aug 09, 2003 at 08:23:53AM -0400, George Gross wrote:
> GSAKMP issue 00
> 
> Section and relevant text passage:
> 
> The document as a whole is missing a comprehensive IANA considerations 
> section. Also the relationship of GSAKMP identifiers to similar ones 
> found in IKE is unspecified.
> 
> Comment/issue description:
> 
> This is similar to the stuff found in IKE-v2 section 6, where there 
> are numerous payload identifiers and crypto algorithms/suites 
> referenced that need IANA to maintain the registry.  WHile the spec
> points to IKE as its template, it is not clear whether you expect 
> to coordinate the GSAKMP payload identifier space (or any of the 
> other identifier spaces, see below) with IKE. Where feasible, it
> would make sense to either converge to a common set with the IKE-v2 
> set of identifiers or else use an non-colliding set of GSAKMP 
> reserved identifiers within the IKE-v2 space.
> 
> Suggested issue resolution:
> 
> 1. Every one of the various tables in the GSAKMP protocol specification 
> that define identifiers should be discussed in the IANA 
> considerations section:
> 	- table 6 group identification types
> 	- table 7 payload types, coordinate with IKE-v2 section 3.2
> 	- table 8 exchange types, coordinate with IKE-v2
> 	- table 9 policy token types
> 	- table 10 key download data types
> 	- table 11 rekey event types
> 	- table 12 identification payload types, coordinate with IKE-v2 section 3.5
> 	- table 13 certificate payload types, coordinate with IKE-v2 section 3.6
> 	- table 14 signature types
> 	- table 15 signature ID types
> 	- table 16 authorization types
> 	- table 17 Notify payload types, coordinate with IKE-v2 section 3.10.1
> 	- table 18 Notify status types, coordinate with IKE-v2 section 3.10.1
> 	- table 19 acknowledgement types
> 	- table 20 key creation type
> 	- table 21 nonce type
> 
> 2. The section 1.2 "Protocol Considerations" belongs as sub-section in 
> the IANA section. This section should specify that GSAKMP is in a 
> UDP payload.
> 
> 3. The generic header payload encoding should be aligned with IKE-v2 
> section 3.2, and it should include the "critical" bit semantics. The 
> GSAKMP mandated payloads should have this bit clear, as explained by 
> the rationale in IKE-v2.
> 
> 4. All of the above identifier/type tables in GSAKMP should have a 
> portion of their identifier space reserved for private/experimental 
> use between consenting parties

-- 
Uri Meth                            (410) 872 - 1515 x233 (voice)
SPARTA, Inc.                        (410) 872 - 8079      (fax)
7075 Samuel Morse Drive             [email-masked]
Columbia, MD 21046

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: George Gross <[email-masked]>
Date: Sun, 7 Sep 2003 23:04:35 -0400 (EDT)

Hi Uri,

> Reposting, as my first attempts did not seem to make it to the list.

have had trouble myself, let's hope the list will stabilize...

> you meant to say ISAKMP.

I think it would be good to start by making sure we're on the same page. I
was referring to IKE-v2, which consolidates ISAKMP and IKE into a single
document.  In particular, I am referring to

http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-10.txt

which the Internet Draft that is moving towards last call as the successor
to ISAKMP/IKE-v1. Please re-review my original e-mail with this in mind,
as it shifts the focus to a different set of requirements/capabilities.

>GSAKMP is similar to ISAKMP in that is uses

The IKE-v2 generic payload definition is found in section 3.2. I am
indicating that GSAKMP payloads should be directly compatible with the
current IKE-v2 spec semantics/syntax, not the ISAKMP/IKE-v1 specs that
were written 6 years ago.  Nor should GSAKMP roll its own payload type
that differs from IKE-v2. In particular, GSAKMP should have the same
concept of a "critical" bit as defined by IKE-v2 in section 3.2 and a set
of Payload Type Values that match those that are already defined by IKE-v2
where they are duplicates in meaning. The following payload types should
be used "as is" from IKE-v2 by GSAKMP:

Certificate
Notify
Delete
Key Exchange
Vendor ID
Nonce
Traffic Selector
IDi for the initiator's identity in the RTJ
a set of payload types reserved for private use

For only those Payload Type Values that are unique to GSAKMP, then there
should be a set of Payload Type Values allocated by IANA that are distinct
from those in use by IKE-v2 but allocated from the same payload type
namespace.

> catch.  We will follow examples from other specs to fill this need.

Again, let's be careful to work from the same pages. The relevant Internet
Drafts to synchronize with are:

http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-03.txt

and section 6 of ipsec-ikev2-10.txt

These IANA related things will be easy to edit into GSAKMP.

There was one other issue mentioned in my original e-mail that I am not

> use between consenting parties

The private/experimental usage should be feasible for all GSAKMP
identifiers, not just its payload type.

br,
	George

---

From: Hugh Harney <[email-masked]>
Date: Mon, 8 Sep 2003 10:00:38 -0400

George,

> be used "as is" from IKE-v2 by GSAKMP:

WRT, the issue of how GSAKMP and the GSAKMP PT should format 
information you have made some broad statements that sound like 
requirements. You state here that GSAKMP should mirror IKEv2 in payload 
structure. Earlier you've stated that the Policy Token work should 
mirror the work done in the AAA working group.

I understand your concerns about interoperability, but these types of 
statements really are changes to the MSEC charter. I don't believe 
interoperability with IKEv2 or AAA is in the MSEC Charter. If you 
really feel that the MSEC charter needs to change I'd suggest you bring 
that up with the chairs.

I think the best path forward is to focus on those issues that flow 
from the MSEC Charter.

Hugh

---

From: George Gross <[email-masked]>
Date: Mon, 8 Sep 2003 13:01:37 -0400 (EDT)

Hi Hugh,

inline below...

> really feel that the MSEC charter needs to change I'd suggest you bring

In most any other IETF working group, you normally would see a chorus of
voices expressing similar views as I've expressed, and they would not have
to cite the charter to have the standards track draft change to reflect
good engineering principals. The MSEC list may be silent, but that does
not change the process. Making GSAKMP integral to other facets of the
Internet architecture is something you design in to minimize re-inventing
the wheel, to make implementations less buggy, and to reduce the need for
various protocols conversion gateways. In the context of making GSAKMP
compatible with IKE-v2, this would allow an IKE-v2 implementation to
extend to handle GSAKMP with fewer bugs, less redundant coding, and
potentially reduce the difficulty of handling GDOI endpoints with that
same implementation. Given these benefits, the burden of explaining why
GSAKMP should not be IKE-v2 compatible as outlined above falls on the
GSAKMP protocol designers, not the MSEC charter.

As a prospective GSAKMP/GDOI implementor, I am not pleased with the
artifical division that has lead to GDOI and GSAKMP occupying the same
Internet. It is incorrect to say "they are different market requirements"
and therefore can proceed independently in parallel. In fact, as a vendor
who bids for business in both the defence and commercial sector, we fully
expect to see secure multicast group deployments formed from mixtures of
GSAKMP and GDOI endpoints. E.g. a DoD agency and an DoD contractor doing a
teleconference. Minimizing the design distance between them will reduce
the effort it takes to realize such applications. To that end, designing
GSAKMP with IKE-v2, GDOI, and AAA considerations is common sense. In fact,
I'd like to see if the differences between GDOI and GSAKMP can be narrowed
to the only the registration SA, and with common logic and protocol for
the rekey, policy token, and TLV encoding aspects.

You've decided to put GSAKMP on standards track, and in this arena until
now, you may not have had the benefit of other parties looking at the
GSAKMP proposed design as vigorously as I have. GSAKMP is not a fait
acomplii. It has the obligation to be a *mallable* design that accepts
feedback, that includes other's requirements besides the co-author's
design decisions. IMHO, there is nothing sacred in its currently drafted
bits on the wire format or its semantics. You don't need a MSEC charter
change to do this.

Only then does GSAKMP have the potential become a proposed standard. And
to date, in my view, the evidence is weighing very mixed wrt/ that
outcome.

 George

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Wed, 10 Sep 2003 13:37:42 -0400

I am trying to understand this. 

Geroge, are you saying that GSAKMP should be re-designed so that it 
becomes GDOIv2 effectively,  or, that the current messages are ok (viz., 
RTJ, KD, Notify:ACK/Fail), but the payloads should be same as in IKEv2?  
Either option would be a serious design change; for example, GSAKMP 
header is quite different from an IKEv2 header.  But, the only rationale 
I heard was that GSAKMP re-design (from tunneled GSAKMP) predates IKEv2 
design. 

As an implementor of GDOI and IKEv2, I would like to see the packet 
headers and even messages of IKEv2 re-used in GSAKMP, however.

cheers,
Lakshminath

---

From: Hugh Harney <[email-masked]>
Date: Wed, 10 Sep 2003 14:49:47 -0400

Lakshminath,

On Wednesday, Sep 10, 2003, at 13:37 US/Eastern, Lakshminath Dondeti 
wrote:

> becomes GDOIv2 effectively,  or, that the current messages are ok 
> (viz., RTJ, KD, Notify:ACK/Fail), but the payloads should be same as 
> in IKEv2?  Either option would be a serious design change; for 
> example, GSAKMP header is quite different from an IKEv2 header.  But, 
> the only rationale I heard was that GSAKMP re-design (from tunneled 
> GSAKMP) predates IKEv2 design.

I actually didn't get to this thread yet.

GSAKMP uses the message structure of ISAKMP, Ref. RFC 2408, Category: 
Standards Track. IKE is a DOI under ISAKMP. Yes, I know people are 
working on IKEv2, but the standard that GSAKMP is written to reference 
is RFC 2408.

I don't believe IKEv2 is intended to replace ISAKMP. It is meant to 
replace IKEv1.

Hugh

---

From: Hugh Harney <[email-masked]>
Date: Wed, 10 Sep 2003 15:05:59 -0400

Lakshminath,

On the subject of GDOI, IKEv2 and GSAKMP.

GSAKMP was never intended to be integrated with IKE. It was intended to 
be a stand alone key management protocol that supported distributed key 
delivery. There is market demand for such a protocol. Several companies 
see this demand and are willing to put money into developing GSAKMP.

I see that there is also a demand for an all encompassing key 
management protocol suite that encompasses the functions of IKEv2 and 
group key management. I've even heard people call this GDOI. Some 
people have even suggested borrowing the security policy piece of 
GSAKMP and incorporating this into GDOI. This was suggested to be named 
GDOIv2. To date GDOIv2 is vapor I-D. I support peoples efforts to 
create this Grand Unifying Key Management Suite. However, I, and 
several others, believe that there is still a need for a stand alone 
key management protocol that provides security for cryptographic 
groups, divorced from IKE and IKE like protocols.

Hugh

wrote:

>>>> concept of a "critical" bit as defined by IKE-v2 in section 3.2 and 
>>>> a
>>>> set
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Wed, 10 Sep 2003 15:11:56 -0400

Please scroll to the end.

> I actually didn't get to this thread yet. 

I saw one of your responses to this thread ;-)!

> I don't believe IKEv2 is intended to replace ISAKMP. It is meant to 
But, you do agree that GSAKMP header is completely different from ISAKMP 
header (included below for quick reference), right? 

There are two issues: payload formats and message formats.  The ISAKMP 
model is to establish a point-to-point tunnel first, and then negotiate 
a CHILD SA within the tunnel.  Thus, GSAKMP message structure is quite 
different from that in RFC 2408.  GSAKMP seems to use the "piggyback" 
technique that IKEv2 uses; thus the comparison to IKEv2.

As George correctly alluded to, product groups want to be able to re-use 
code where possible.  That's the motivation behind my message.

regards,
Lakshminath

ISAKMP header:

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                          Initiator                            !
    !                            Cookie                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                          Responder                            !
    !                            Cookie                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                          Message ID                           !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            Length                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

GSAKMP header:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    !Group ID Type  !      Group ID Value                           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ~               ! Next Payload  !   Version     ! Exchange Type !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! Sequence ID                                                   !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
    ! Length                                                        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

---

From: Hugh Harney <[email-masked]>
Date: Wed, 10 Sep 2003 15:21:17 -0400

Lakshminath,

> But, you do agree that GSAKMP header is completely different from 
> ISAKMP header (included below for quick reference), right?

GSAKMP uses the payload structures in ISAKMP.

> model is to establish a point-to-point tunnel first, and then 
> negotiate a CHILD SA within the tunnel.  Thus, GSAKMP message 
> structure is quite different from that in RFC 2408.  GSAKMP seems to 
> use the "piggyback" technique that IKEv2 uses; thus the comparison to 
> IKEv2.

Piggyback? I'm not sure of the reference. We used the payload formats 
in ISAKMP. Yes, IKE also used many of the payloads of ISAKMP. I'm 
pointing out that we copied from the parent not the child.

> As George correctly alluded to, product groups want to be able to 
> re-use code where possible.  That's the motivation behind my message.

So your saying that there is no room a GSAKMP standard unless it 
conforms to IKEv2?

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Wed, 10 Sep 2003 15:28:35 -0400

Yes.  I understand this (as it was explained to me before :-) ).  
However, when I saw George's message about modeling GSAKMP payloads 
after IKEv2 payloads, I was not sure whether there was a change in 
plans.  Apparently not!

I do have a comment on GSAKMP and its applicability as you explain 
below.  It appears that GSAKMP connects to points at the top and the 
bottom of the ISAKMP family, i.e., GSAKMP's relationship with ISAKMP and 
IPsec.  That probably is the cause for the repeated confusion on the 
design of GSAKMP.

Once the relationship to IPsec is found as a common point, one can 
imagine (as George did) a scenario where there may be a GCKS that 
supports both GSAKMP and GDOI registration protocols, that share a 
common GSA.  The questions about (or requests for accommodating) code 
re-use etc., follow from that.

best regards,
Lakshminath

PS:  GDOIv2 efforts - I have some interest in that TBD protocol - would 
be premature until IKEv2 goes through IESG last call.  Once that is 
complete, I am sure we will see an I-D.

Hugh Harney wrote:

> GSAKMP was never intended to be integrated with IKE. It was intended 
> to be a stand alone key management protocol that supported distributed 
> key delivery. There is market demand for such a protocol. Several 
> companies see this demand and are willing to put money into developing 
> GSAKMP.
>
> GSAKMP and incorporating this into GDOI. This was suggested to be 
> named GDOIv2. To date GDOIv2 is vapor I-D. I support peoples efforts 
> to create this Grand Unifying Key Management Suite. However, I, and

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Wed, 10 Sep 2003 15:39:18 -0400

> GSAKMP uses the payload structures in ISAKMP.

I agree that some of the payloads and the generic header are reused and 
I appreciate that.  But, the main header is different.

>
>> There are two issues: payload formats and message formats.  The 
>> ISAKMP model is to establish a point-to-point tunnel first, and then 

Piggybacking is an IKEv2 reference (Sec 2.17 of -10-).  Please see my 
other email addressing your other comments.

> So your saying that there is no room a GSAKMP standard unless it 

No, I am not saying that.  Although I don't like the three message 
version (I explained why and Andrea and I exchanged some emails on that 
CC'ed to the list, a while ago), if there is a need for the GSAKMP 
design (to me it is distributed group management, PT etc.), great.  But, 
I just hope that IKEv2 payloads and if possible messages (does the DoS 
protection stuff already do this?), and other techniques (e.g., NAT 
traversal that George pointed to) can be used intact.

best regards,
Lakshminath

---

From: Hugh Harney <[email-masked]>
Date: Wed, 10 Sep 2003 15:57:50 -0400

Lakshminath,

>  if there is a need for the GSAKMP design (to me it is distributed 
> group management, PT etc.), great.

That was the intent.

>  But, I just hope that IKEv2 payloads and if possible messages (does 
> the DoS protection stuff already do this?), and other techniques 
> (e.g., NAT traversal that George pointed to) can be used intact.
>

We adopted the IKEv2 cookie concepts. I'm still trying to see the 
requirement for inclusion of IKEv2 NAT transversal in a group context. 
The whole concept of negotiation of group secure data delivery 
parameters is a bit strange to me. If there is negotiation, I think it 
is needed prior to the GO creating a policy token. My issue with this 
is that the group should provide a common level of service for group 
data delivery. To allow the negotiation of different levels of service 
means that the level of data protection drops to the lowest level of 
negotiation, for the entire group. This bothers me.

Hugh

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Wed, 10 Sep 2003 16:32:29 -0400

Hugh,

Just to clarify, I don't mean that any thing should be negotiated in the 
group context; thus, all group security parameters are downloaded. 

Within the context of the point-to-point connection established for the 
download process, NAT traversal etc., needs to be addressed.

Lakshminath

---

From: Hugh Harney <[email-masked]>
Date: Wed, 10 Sep 2003 16:56:33 -0400

On Wednesday, Sep 10, 2003, at 16:32 US/Eastern, Lakshminath Dondeti 
wrote:

> Hugh,
>
> Just to clarify, I don't mean that any thing should be negotiated in 
> the group context; thus, all group security parameters are downloaded.
> Within the context of the point-to-point connection established for 
> the download process, NAT traversal etc., needs to be addressed.

I guess I'm a bit lost here. I assume we can get communication between 
the GM and GC/KS. Remember the GM is initiating the contact. GSAKMP 
doesn't use the IP address for identification of the endpoint, so do I 
care that it is changed by a NAT?

I agree that it may be difficult to tell the data layer security 
service that the key is for the broadcast on IP address x.y.p. However, 
we can tell the GM that the key is for group ID 123, where 123 is 
unique. The mapping of group ID to multicast traffic can be handled in 
many ways - announcements, web pages, registration sites...

I'm missing the issue here. Please help me out.

Hugh

---

From: Mark Baugher <[email-masked]>
Date: Wed, 10 Sep 2003 17:58:08 -0700

Hugh
   I don't see how GSAKMP can be said to reference RFC 2408 when the header 
of GSAKMP messages is incompatible with 2408.

Mark
At 02:49 PM 9/10/2003 -0400, Hugh Harney wrote:
>Lakshminath,
>
>
>On Wednesday, Sep 10, 2003, at 13:37 US/Eastern, Lakshminath Dondeti wrote:
>
>>RTJ, KD, Notify:ACK/Fail), but the payloads should be same as in 
>>IKEv2?  Either option would be a serious design change; for example, 
>>GSAKMP header is quite different from an IKEv2 header.  But, the only 
>>rationale I heard was that GSAKMP re-design (from tunneled GSAKMP) 
>>predates IKEv2 design.
>Standards Track. IKE is a DOI under ISAKMP. Yes, I know people are working 
>on IKEv2, but the standard that GSAKMP is written to reference is RFC 2408.
>

---

From: Mark Baugher <[email-masked]>
Date: Wed, 10 Sep 2003 17:59:55 -0700

Hugh
   I don't think that compatibility with RFC 2408 is on the report card for 
GSAKMP.  It is inspired by ISAKMP and the names look similar.  Beyond that, 
it is pretty different.

Mark
At 03:21 PM 9/10/2003 -0400, Hugh Harney wrote:
>>model is to establish a point-to-point tunnel first, and then negotiate a 
>>CHILD SA within the tunnel.  Thus, GSAKMP message structure is quite 
>Piggyback? I'm not sure of the reference. We used the payload formats in 
>ISAKMP. Yes, IKE also used many of the payloads of ISAKMP. I'm pointing 
>out that we copied from the parent not the child.
>
>So your saying that there is no room a GSAKMP standard unless it conforms 
>to IKEv2?
>
>

---

From: Hugh Harney <[email-masked]>
Date: Thu, 11 Sep 2003 09:47:51 -0400

Mark,

I like the idea of a report card. : ) It brings to mind an IETF school.

We took as much of the payload formats as we could, but your right it 
is not fully compliant.

The topic of payload formats was brought up by someone.

hugh

On Wednesday, Sep 10, 2003, at 20:59 US/Eastern, Mark Baugher wrote:

> Hugh
>   I don't think that compatibility with RFC 2408 is on the report card 
> for GSAKMP.  It is inspired by ISAKMP and the names look similar.  
> Beyond that, it is pretty different.
>
> Mark
>>> use the "piggyback" technique that IKEv2 uses; thus the comparison 
>>> to IKEv2.
>>
>>> re-use code where possible.  That's the motivation behind my >>> message.
>>
Hugh Harney							Sparta, Inc.

---

From: Haitham Cruickshank <[email-masked]>
Date: Thu, 11 Sep 2003 17:50:50 +0100

Hi Hugh,

I completely agree with you on the need for a stand alone key management protocol
that support distributed key delivery like GSAKMP.  Having one of msec protocols
(like GSAKMP) completely divorced :)  from IKE is a good idea.  Yesterday we had
IKE-v1, today we have IKE-v2, who knows about tomorrow.  In addition, we still have
problems with IPSEC regarding multicast.  So an independent protocol is good and
safe.

Haitham

--
Dr. Haitham S. Cruickshank

Senior Research Fellow in Communications
Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey
Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: [email-masked]
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/

---

From: Mark Baugher <[email-masked]>
Date: Thu, 11 Sep 2003 10:41:31 -0700

Haitham,

At 05:50 PM 9/11/2003 +0100, Haitham Cruickshank wrote:
>problems with IPSEC regarding multicast.

Which problems are you referring to here?

thanks, Mark

>So an independent protocol is good and
>safe.
>
>Haitham
>
>Hugh Harney wrote:
>
> > Lakshminath,
> >
> > Hugh Harney                                                     Sparta, 
> Inc.

---

From: Haitham Cruickshank <[email-masked]>
Date: Fri, 12 Sep 2003 17:01:33 +0100

Hi Mark,

> >problems with IPSEC regarding multicast.

I had a quick read through the ESP latest draft (draft-ietf-ipsec-esp-v3-06.txt).
It seems that most multicast issues are solved except that there is no anti-replay
mechanism for multi-sender SA (Shared SA among multiple senders), which I think is
not a big issue.  Therefore I am glad that I was wrong and we are inline with
IPSEC.