Subject: [Mip6] WG LC (Deadline Dec 18th, 04) for I-Ds: draft-ietf-mip6-auth-protocol-01.txt and draft-ietf-mip6-mn-ident-option-00.txt

From: [email-masked]
Date: Fri, 10 Dec 2004 17:57:24 -0600

This is a Working Group last call for the following I-Ds:
1. I-D : draft-ietf-mip6-auth-protocol-01.txt
Title: Authentication Protocol for Mobile IPv6

2. I-D: draft-ietf-mip6-mn-ident-option-00.txt
Title: MN Identifier Option for Mobile IPv6

The status associated with these I-Ds is : Informational and will be
progressed as such.

Please review and post your comments by December 18th, 2005.
Note that the duration of the WG LC for these I-Ds is only one week
because of the 3GPP2 dependency.

-Chairs

URL to I-D:
1. http://www.ietf.org/internet-drafts/draft-ietf-mip6-mn-ident-option-00.txt
2. http://www.ietf.org/internet-drafts/draft-ietf-mip6-mn-ident-option-00.txt

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

---

From: "Junghoon Jee" <[email-masked]>
Date: Mon, 13 Dec 2004 10:30:38 +0900

Basavaraj,
Minor correction for your email.

progressed as such.

>1. http://www.ietf.org/internet-drafts/draft-ietf-mip6-mn-ident-option-00.txt
=> http://www.ietf.org/internet-drafts/draft-ietf-mip6-auth-protocol-01.txt

>2. http://www.ietf.org/internet-drafts/draft-ietf-mip6-mn-ident-option-00.txt

Junghoon.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 Dec 2004 15:24:22 +0100

In your previous mail you wrote:

=> some comments:
 - in 1 Introduction: IPsec SAs always come by pairs so either plural or
   the word pair is needed. BTW "SA" should be replaced by security
   association (in particular in an introduction without a previous
   definion :-).
 - Acknowldegement (sp)
 - Home agents however have to implement and support... This statement
   must be put in a context, i.e., it doesn't apply in general.
 - 4 operational flow: the figure mixes IPv6 extensions, IPv6 options
   and mobility header options:
    * HoA option is an IPv6 destination option
    * RH-2 is an extension header, not an option.
 - 5.1 MN-HA auth mob option: the shared security association is not
   introduced at all so the application consideration is out of any
   context...
 - 5.2 MN-AAA auth mob option: the BA is not protected. This is a
   major security issue.
 - the authentication options are *options*, not extensions.
 - 5.3 auth failure: please replace error code by status
 - 6 message indent: anti-replay is important, IMHO at least SHOULD is
   required.
 - 7 security considerations: the text says the new options provide
   authentication of BU and BA messages. This is not true for BAs.
   (I don't propose to fix the security considerations but the protocol)
 - another point: MD5 should be replaced by SHA-1 everywhere in the document.

=> until the ident option is used in another context I can't see a reason
to not merge the two documents.

Regards

[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Dec 2004 11:08:17 -0800

>  - 6 message indent: anti-replay is important, IMHO at least SHOULD is

in most cases, the sequence number in the Binding Update is
enough for replay protection when the authentication option
protocol is used. if in a particular deployment, (which uses
the authentication option protocol), the sequence number is
not sufficient, the message identification option should be
used. that why it is a MAY in the document.

Vijay

---

From: Charlie P <[email-masked]>
Date: Tue, 14 Dec 2004 12:48:55 -0800

Hello Vijay,

As best I can remember, the replay protection is sufficient
for all cases except when all of the following are made to
be true:
- The home agent has to reload the security association
   with the mobile node each time it (?reboots? ?is allocated?)
- The home agent cannot store or reload the sequence number
   along with the security association
I believe that when these conditions hold, it doesn't really
help if the mobile node has nonvolatile memory.  On the
other hand, I feel it is somewhat of a design error for the
home agent to be constructed in this way, and it would
not usually be done that way except for certain legacy
system designs.

Furthermore, even in this case, I believe that the home
agent could supply a timestamp-based initial sequence
number to the mobile node along with error #135, and
the extension wouldn't be needed even in that case.
However, there is no harm in allowing the extension.
Thus, I believe that "MAY" is appropriate.

Regards,
Charlie P.

---

From: Kent Leung <[email-masked]>
Date: Tue, 14 Dec 2004 16:05:32 -0800

Hi Charlie.

To provide replay protection using the Sequence Number field, the HA
must store this state permanently after MN registration.  Otherwise,
a replay attack can be successful when MN has deregistered or BCE
timed out.  However, the value of such attack is debatable.

>RFC 3775 section 9.5.1:
>    If the receiving node has no Binding Cache entry for the indicated
>    home address, it MUST accept any Sequence Number value in a received
>    Binding Update from this mobile node.

In an environment where MNs are dynamically assigned to an HA, storing
the SA and Sequence Number states permanently for all MNs appears
to be unsuitable.  Arguably correct is the minute consumption of memory
to support the states.  In the case when SA is dynamically generated
during initial registration, the Sequence Number is sufficient because
replays will fail authentication (using old SA).  The timestamp option still
has value for optimizing the signaling when MN and HA are synchronized.

I believe "MAY" is fine.

Kent

--
      |           |                   Kent Leung
     :|:         :|:                  IP Mobility Development
    :|||:       :|||:                 IOS Technologies Division
   :|||||||:   :|||||||:              Voice: 408.526.5030
.:|||||||||:.:|||||||||:.             Fax:   408.525.1653
  c i s c o S y s t e m s             Email: [email-masked]

---

From: "James Kempf" <[email-masked]>
Date: Tue, 14 Dec 2004 17:41:48 -0800

>  - another point: MD5 should be replaced by SHA-1 everywhere in the
document.

Yes, this can't be emphasized strongly enough.

Results by Xiaoyun Wang from China presented at Crypto in Santa Barbara this
summer showed that with 1 hr of precomputation on IBM P690, new collisons on
1024 bit messages could be generated every 15 sec. to 5 min. MD5 should be
considered insecure and not used, and it should be EOL-ed in existing IETF
protocols and replaced with SHA-1.

SHA-1 appears to be secure after 40 rounds but has been broken up to 40 (it
typically takes 80), which appears to be the limit possible with the current
cryptanalysis technique. Whether its possible to break SHA-1 completely,
remains to be seen.

                    jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 15 Dec 2004 14:51:25 -0800

> - 5.2 MN-AAA auth mob option: the BA is not protected. This is a
HA _could_ include MN-HA auth option in the BA.

Also, I have few nits:

- replace HAAA by AAAH
- Authenticator is not a good term. It reflects a node rather than data. 
How about Authentication Data?
- Section 5.2: is CHAP_SPI the only value defined? If so, the following 
statement should remove "When" to disambiguate.
- Bootstrapping session key with HA using MN-AAA authentication is 
deliberately omitted? Perhaps making it clear would be useful.
- I guess NAI is not optional in the BU containing MN - AAA auth option? 
Please fix the operational flow diagram/text

Regards,

-Rajeev

---

From: Kent Leung <[email-masked]>
Date: Thu, 16 Dec 2004 13:34:23 -0800

Hi James.

Acknowledged.  Unless there's disagreement, we'll replace MD5 context
with SHA-1 in the document.

Thanks.

Kent

---

From: Wing Cheong Lau <[email-masked]>
Date: Thu, 16 Dec 2004 14:33:53 -0800

>with SHA-1 in the document.
Dear Kent,

Once you replace MD5 with SHA-1, will you be proposing corresponding 
extensions/ changes to
RADIUS and CHAP so that one can use RADIUS/CHAP to authenticate a BU using 
MN-AAA authentication
option in your draft ? (there is no mentioning of SHA-1 in RFC2865 or RFC 
1996 so far).

If not, how will the MN-AAA option interoperate with the AAA ?

Regards,

Wing

---

From: "alpesh" <[email-masked]>
Date: Thu, 16 Dec 2004 14:39:26 -0800

Rajeev -

Thanks for the comments, please see inline ... 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Rajeev Koodli
> Sent: Wednesday, December 15, 2004 2:51 PM
> To: Francis Dupont
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Mip6] WG LC (Deadline Dec 18th,04) for I-Ds: 
> draft-ietf-mip6-auth-protocol-01.txtand 
> draft-ietf-mip6-mn-ident-option-00.txt
> 
> 
> 
> Francis Dupont wrote:
> 

Correct, that was an oversight - has been fixed now.

> - replace HAAA by AAAH
Sure.

> How about Authentication Data?

Resonable.

> - Section 5.2: is CHAP_SPI the only value defined? If so, the 
> following statement should remove "When" to disambiguate.

Changed to have HMAC_SHA1 as the only algorithm now.

> - Bootstrapping session key with HA using MN-AAA 
> authentication is deliberately omitted? Perhaps making it 
> clear would be useful.

Yes, that is intentional to maintain the scope of the draft and converge in
a timely manner. We may publish the session key generation draft soon.

> - I guess NAI is not optional in the BU containing MN - AAA 

Well, it can be optional - if the AAA uses IP address to identify the MN and
MN
Uses static addresses. We are keeping it optional (since the base draft uses
static
IP addresses).

> Please fix the operational flow diagram/text

Per Francis's comments, right? If so, I have modified it.

Thx
-a

---

From: Kent Leung <[email-masked]>
Date: Thu, 16 Dec 2004 15:04:21 -0800

Hi Wing.

This is a generic issue, lack of RADIUS AVPs to identify authentication
method to the AAA server.  This was also raised in MIP4 WG for
3012bis.  That draft is proceeding forth with admission to this fact.
There needs to be an I-D in RADEXT WG to deal with
this generic AAA issue.  We plan to submit an I-D there.

Kent

---

From: "James Kempf" <[email-masked]>
Date: Fri, 17 Dec 2004 04:24:47 -0800

I'd suggest that someone write a draft for the radext WG proposing MD5 be
replaced with SHA-1.

I doubt that the security directorate will let draft-ietf-mip6-auth-protocol
progress, even as Informational, if MD5 is in it.

        jak

----- Original Message ----- 
From: "Wing Cheong Lau" <[email-masked]>
To: "Kent Leung" <[email-masked]>; "James Kempf"
<[email-masked]>
Cc: <[email-masked]>; "Francis Dupont" <[email-masked]>;
<[email-masked]>
Sent: Thursday, December 16, 2004 2:33 PM
Subject: Re: [Mip6] WG LC (Deadline Dec 18th, 04) for I-Ds:
draft-ietf-mip6-auth-protocol-01.txt
anddraft-ietf-mip6-mn-ident-option-00.txt

---

From: "alpesh" <[email-masked]>
Date: Fri, 17 Dec 2004 09:38:13 -0800

James  -

Agree. I have moved on HMAC_SHA1/SHA1 where appropriate.

As Kent mentioned, we are working on a draft to do SHA-1 auth for
Radext WG

-a 

> Behalf Of James Kempf
> Sent: Friday, December 17, 2004 4:25 AM
> To: Kent Leung; Wing Cheong Lau
> Cc: [email-masked]; Francis Dupont; [email-masked]
> draft-ietf-mip6-auth-protocol-01.txtanddraft-ietf-mip6-mn-iden
> t-option-00.txt 
> 
> I'd suggest that someone write a draft for the radext WG 
> proposing MD5 be replaced with SHA-1.
> 
> I doubt that the security directorate will let 
> draft-ietf-mip6-auth-protocol progress, even as 
> Informational, if MD5 is in it.
> 
>         jak
> 
> > >> >  - another point: MD5 should be replaced by SHA-1 
> everywhere in the
> > >>document.
> > >>
> > >>Results by Xiaoyun Wang from China presented at Crypto in 
> Santa Barbara
> this
> > >>1024 bit messages could be generated every 15 sec. to 5 
> min. MD5 should
> be
> > >>considered insecure and not used, and it should be EOL-ed 
> in existing
> IETF
> > >>SHA-1 appears to be secure after 40 rounds but has been 
> broken up to 40
> (it
> > >>typically takes 80), which appears to be the limit 
> possible with the
> current

---

From: Jari Arkko <[email-masked]>
Date: Sat, 18 Dec 2004 21:47:21 +0200

I have reviewed this document. Here are my comments:

Substantial:

> [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.

It may be appropriate to refer to draft-ietf-radext-rfc2486bis-03.txt
instead. This document is in IETF LC at the moment, which means that
its in front of the ident-option draft; reference delay should not
be a problem. One good reason for switching to the bis reference
is that the ABNF in the original RFC had a number of problems.

> If this option is present in the Binding Update, it MUST be included in the corresponding reply (Binding Acknowledgement).

Hmm... why? Does not seem to be grounds for a MUST. But I wonder
why you need it in the first place.

> 5.  IANA Considerations

This one is missing the text about the subtype registry.
Here's a suggestion:

    In addition, the IANA needs to create a new namespace for
    the subtype field of the Mobile Node Identifier Option.
    The currently allocated values are as follows:

        NAI (defined in this document)      [1]

    New values for this namespace can be allocated using
    Standards Action [RFC 2434].

> it MUST be present in all subsequent Binding Updates
> used to renew the binding cache entry.

Is this really necessary? Presumably you could store
the identifier in the BCE. This would also provide
some privacy benefits, see also below.

> 4.  Security Considerations
> 
>     None.  This document defines new identifiers for a mobile node and
>     does not introduce new security threats.

I don't think this covers it completely. Here's some suggested
text that deals with a few issues:

    Mobile IPv6 already contains one mechanism for identifying
    mobile nodes, the Home Address Option [RFC 3775]. As a result,
    the vulnerabilities of the new option defined in this document
    are similar to those that already exist for Mobile IPv6. In
    particular, the use of a permanent, stable identifier may
    compromise the privacy of the user, making it possible to
    track a particular device or user as it moves through
    different locations.

    In addition, since an NAI reveals the home affiliation
    of a user, it may assist an attacker in determining the
    identity of the user, help the attacker in targeting
    specific victims, or assist in further probing of
    the username space.

    These vulnerabilities can be addressed through various
    mechanisms, such as those discussed below:

    o  Encrypting traffic at link layer such that other
       users on the same link do not see the identifiers.
       This mechanism does not help against attackers on
       the rest of the path between the mobile node and
       its home agent.

    o  Encrypting the whole packet, such as when using
       IPsec to protect the communications with the home
       agent [RFC 3776].

    o  Using an authentication mechanism that enables the
       use of privacy NAIs [RFC2486bis] or temporary,
       changing "pseudonyms" as identifiers.

    In any case, it should be noted that as the identifier
    option is only needed on the first registration at the
    home agent and subsequent registrations can use the
    home address, the window of privacy vulnerability in
    this document is reduced as compared to the RFC 3775.
    In addition, this document is a part of a solution to
    allow dynamic home addresses to be used. This is
    an improvement to privacy as well, and affects both
    communications with the home agent and the correspondent
    nodes, both of which have to be told the home address.

> The MN-NAI mobility option uses an identifier of the form user@realm
> [RFC2486].

Perhaps you could indicate whether you allow the use of
the privacy, internationalization, or bang syntaxes from
RFC2486bis.

Editorial:

> Alignment requirements:
> 
> This option does not have any alignment requirements.

This looks like a field description. Change to:

> This option does not have any alignment requirements.

(That is, indent as regular text and delete the heading.)

> Title: MN Identifier Option for Mobile IPv6

Change to "Mobile Node Identifier Option for Mobile IPv6".

> 3.  MN Identifier option 3.1  MN-NAI mobility option

I guess I'm confused here. You are defining just one
Mobile IPv6 option. I think its name should be the "Mobile
Node Identifier Option". If you want to have a subsection 3.1
to talk about the case when the type of identifier is a NAI,
that's fine. But the current 3.1. sounds like you were defining
another option.

> authentication enabling extension

Change to "authentication related extension"

> IANA should record value for this new Mobility Option.

... should record *a* value ...

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 19 Dec 2004 11:31:07 +0200

(I'm hoping its still Dec 18th somewhere in the world.)

I have reviewed this document. Like the identifier draft,
its in pretty good shape, and as I have stated before I
do believe we need to have support for AAA-based
authentication.

But there are a few issues that need to be corrected. The most
important issue is putting back the mandatory support for RO/RR.
Also, I have identified a number places where the document could
define a simpler protocol.

Here are my comments:

Substantial:

> The confidentiality protection of Return Routability messages
> and ... is outside the scope of this document.

I do not think this is appropriate for the following reasons:

o  Route optimization relies on encryption of HOTI messages
    as they pass through the home agent.
o  Route optimization is an integral part of Mobile IPv6.
o  In practise you cannot control where this authentication
    option is used. (I do agree that in the 3GPP2 environment
    the usage would be safe, but that's besides the point.)

As a result of not protecting the HOTI messages you are in
effect breaking Mobile IPv6's route optimization, because
we can no longer trust that everyone is capable of doing it
in a secure manner. You are also deviating from the base
RFC which requires support for HOTI protection.

Fortunately, protecting the HOTI messages is very easy, as
has been demonstrated in an earlier version of your draft.
And it does not require IPsec. Please put the support back
in.

Note that I'm not arguing that you have to use this
protection. Like in RFC 3775 & 3776, the use of
the encryption can be optional. But we really need to
make it mandatory to implement.

> MN MAY use Message Identifier option as defined in Section 6 for
> replay protection.
> ...
> The format of the timestamp mobility option is as defined in Section
> 6.  This option uses the subtype value of 1.  The Identification
> field carries timestamp for replay protection.

I am somewhat concerned about the extensive optionality and
additional replay protection schemes, from a complexity point
of view. Do we really expect that there is going to be yet
another replay protection schemes? Is there a reason why
we don't want to use the option all the time? Ease of analysis &
implementation simplicity would be some of the benefits...

> Also, this rejection and using sequence
> number as a nonce in rejection is a new behavior that is not
> specified in [RFC3775].

This seems to contradict my understanding. See Section 9.5.1
and Status code 135 usage.

> Subtype:
> 
>   A number assigned to identify the entity and/or mechanism to be
>   used to authenticate the message.

I think it would make more sense for this draft to define
the specific authentication mechanism, and not act as a general
purpose format which could be extended for other authentication
mechanisms in the future.

>       |                   BU to HA                           |
> (a)   |----------------------------------------------------->|
>       | (HoA option, MN-ID option [optional],                |
>       |  Message ID option [optional], authentication option)|

Why is the home address option mandatory in this figure? One
of the benefits of this mechanism should be that a home address
could be allocated by the home agent during the authentication
process.

Actually, I think you want at least one of HOA and NAI options.
And you should explicitly define the semantics. That is, if
you don't have a NAI then you must have a HOA, and the secret
is looked up based on the HOA. If you have a NAI only, you
look up the secret and the HOA based on that. If you have
both, they must match (NAI must be authorized to use the
home address).

> MN MUST include this option in a BU if it shares a security
> association with the HA.  HA MUST include this option in the BA if
> IPsec is not used and it has a security association with the MN.

A "security association" may be too general. Its a security
association of a certain kind that you need, not others. For
instance, if the MN has only an IPsec SA or a TLS association with
the home agent, they should not attempt to use this option.
Suggestion: give a name X for your authentication method and
start referring to the "X security associations". Here X
could be, say, "Shared-Key Mobile IPv6 Authentication".

> The value 5 is reserved for use by 3GPP2.

This seems strange. If 3GPP2 wants the IETF to define an
RFC for a new feature within Mobile IPv6, you would expect
the semantics of value 5 to be defined. Which algorithms
are 3GPP2 actually using? Or is the value 5 just a relic
from older systems, dealing with Mobile IPv4?

> 8.  IANA Considerations

Both Subtype fields are missing. New namespaces need to
be created. I'd actually prefer to simplify the draft
by not including all such generality -- we have enough
Mobility Options to allocate new stuff if necessary.
But if you keep the subtypes, you need a Standards
Action or IESG Approval [RFC 2434] procedure for
allocating new ones.

> 5.1   MN-HA authentication mobility option . . . . . . . . . . .  8
>   5.1.1   Processing Considerations  . . . . . . . . . . . . . .  9
> 5.2   MN-AAA authentication mobility option  . . . . . . . . . .  9
>   5.2.1   Processing Considerations  . . . . . . . . . . . . . . 10

I am curious as to why we need both. Where the 2-message authentication
scheme is appropriate, it seems that a CHAP-style scheme is adequate.
In other areas we don't usually see the fact that there is or is not
AAA at the other side. For instance, we don't know that in PPP, we
don't know that in WLAN. (There are certain reasons for knowing what's
on the other side, but the protocols for that are pretty far from
what is done here; I don't think that is the intention here.) So why
do we need more than the Section 5.2? Or is this again something
inherited from the Mobile IPv4 side?

But I may be missing something obvious. In any case, it would
really help if people would post what exactly the 3GPP2 intends
to use from this draft, all options or just some.

Editorial:

General: I tend to like "the mobile node ..." type of text better
than "the MN ...". But maybe that's a personal preference.

> MN MAY use NAI option as defined in [MN_Ident] to identify itself

I believe the correct name for the option is "Mobile Node Identification
option", not the "NAI option". But are you saying that you can
use only subtype 1 identifier, the NAI? Better not say anything,
just say that you can use the option.

> Upon receiving a BU from the MN, the HA SHALL extract the MN-AAA

SHALL? Maybe MUST instead?

> 6.  Mobility message identification option

I got confused a couple of times, thinking this was
a mobile node identification option. The purpose of
the option in this document, however, is replay protection.
Suggest using "replay" or "timestamp" somewhere in the
name. Maybe "Mobility Replay Protection Option".

> The value 2 is suggested for CHAP_SPI as defined in section Section
> 5.2.
> 
> The value 3 is suggested for HMAC_SHA1.

Is value 3 what is being described in Section 5.1? If yes,
say so. If no, I may be confused.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Dec 2004 16:08:08 +0100

=> I have no concern to get the function from the "deployment
environment" but in this case the constraints for the "deployment
environment" must be explicited (currently we can only assume
that the "deployment environment" provides authentication and
authorization). Note it is possible the "deployment environment"
needs the sequence number...

Regards

---

From: AC Mahendran <[email-masked]>
Date: Tue, 21 Dec 2004 13:18:04 -0800

>define a simpler protocol.

Hi Jari,

3GPP2 is on a very tight schedule. We need this draft published at the 
earliest to meet 3GPP2's deadline. The RO/RR support has been discussed a 
lot in the past and the authors were requested to remove it from the 
specification. I am not sure whether it is worthwhile to go through these 
discussions once more. If needed, we can always address the RR encryption 
in another draft.

Thanks,
AC

---

From: "alpesh" <[email-masked]>
Date: Tue, 21 Dec 2004 13:19:16 -0800

Francis -

The specific case is described in an appendix (B in the version you have).
It is
In appendix A (in version that will be submitted shortly).

-a 

> Behalf Of Francis Dupont
> Sent: Monday, December 20, 2004 7:08 AM
> To: Vijay Devarapalli
> environment" but in this case the constraints for the 
> "deployment environment" must be explicited (currently we can 
> only assume that the "deployment environment" provides 
> authentication and authorization). Note it is possible the 
> "deployment environment"

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 Dec 2004 13:17:50 -0800

Hello folks,

... by dialup ...

I'm hoping to get my comments typed in before the
telephone line crashes again...  I may have missed
some of the discussion since I'm not completely
caught up yet.

> important issue is putting back the mandatory support for RO/RR.
Protecting RO/RR is a good idea, and I don't think it is too
hard.  However, I believe it is "highly recommended" and not
"mandated", and could be done later.  I'd hate to see that hold
up the progress of this draft.

> implementation simplicity would be some of the benefits...

I am much opposed to making the extra timestamp scheme
mandatory.  It isn't needed in many or perhaps even most
cases, and it does impose additional implementation burden.
Plus it is extra baggage.

> could be, say, "Shared-Key Mobile IPv6 Authentication".

I think it would be enough to say in the beginning of the
draft something along the lines:

    In this draft, a "security association" is understood to
    be a "Shared-Key Mobile IPv6 Authentication" security
    association.

> from older systems, dealing with Mobile IPv4?

In fact, I believe the SPI field should be optional at best,
since almost always there is only one such security association
that would be used with the option.  It could be a different
subtype, or it could be omitted altogether.

................

More soon, not wanting to push my luck here...

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Dec 2004 14:00:12 +0200

Hi Charlie,

> hard.  However, I believe it is "highly recommended" and not

Yes. I agree about the status.

> up the progress of this draft.

I agree, but all I want to do is to keep the level of support
required in the base RFC. That is, mandatory to implement
and optional to use. SInce text already exists, I don't think
the draft will be delayed much.

--Jari

---

From: "alpesh" <[email-masked]>
Date: Thu, 23 Dec 2004 07:45:48 -0800

Jari -

> required in the base RFC. That is, mandatory to implement and 
> optional to use. SInce text already exists, I don't think the 
> draft will be delayed much.
> 
> --Jari

Confused a bit here - "text already exists" from the pre-WG item stages?
If so, I agree, but then, we did not have much discussion/review on it. I am
afraid that reintroducing it will cause undue delay. We are working on
introducing that as a separate draft to avoid holding up this draft.

-a

---

From: Francis Dupont <[email-masked]>
Date: Thu, 30 Dec 2004 15:03:58 +0100

=> I did not understand your answer the first time but now with the
02 version of the draft it is clear.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 30 Dec 2004 15:26:18 +0100

=> appendixes are not "normative" so there is still a formal issue.
I am reading the new (02) version:
 - MN-HA has the anti-replay in its SA, even there is no detail I believe
   there will no problem with not totally stupid implementations.
 - MN-AAA has still the problem and in 5.2.1.1 no anti-replay stuff is
   sent to the AAA server. BTW there is no reference to the AAA application
   used in 5.2.1.1 so one can infer from the whole draft that the message
   identification option is highly recommended with MN-AAA.
   As it is not the case the text should be improved...

Regards