RE: [netlmm] Issue: Auth Option support
"Alper Yegin" <alper.yegin@yegin.org> Tue, 11 September 2007 08:24 UTC
Return-path: <netlmm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV12b-0000qJ-1n; Tue, 11 Sep 2007 04:24:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV12Z-0000q9-EA for netlmm@ietf.org; Tue, 11 Sep 2007 04:24:11 -0400
Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV12Y-0002na-2c for netlmm@ietf.org; Tue, 11 Sep 2007 04:24:11 -0400
Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IV12J3kwT-0007QD; Tue, 11 Sep 2007 04:24:04 -0400
From: Alper Yegin <alper.yegin@yegin.org>
To: 'Vijay Devarapalli' <vijay.devarapalli@azairenet.com>
Subject: RE: [netlmm] Issue: Auth Option support
Date: Tue, 11 Sep 2007 11:23:42 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: Acfz5rK72M0GJomDTU21kHdeHLPJggAZei3g
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
In-Reply-To: <46E5A4CE.2090008@azairenet.com>
Message-Id: <0MKpCa-1IV12J3kwT-0007QD@mrelay.perfora.net>
X-Provags-ID: V01U2FsdGVkX18KWhZtUxILZ/3cQEFbXEH2J47QCUF9ZeW7j4V wwZqNErpsbewMWjuy7qGWpNDsU6+xT7UeDiPMAORL8CkC/PmCR JYGFfrf+oTUGgb/Vt7K7w==
X-Spam-Score: -0.0 (/)
X-Scan-Signature: 43317e64100dd4d87214c51822b582d1
Cc: netlmm@ietf.org
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
Errors-To: netlmm-bounces@ietf.org
> Alper Yegin wrote: > > Vijay, > > > > Where did you get that idea ("SHOULD" is not useful for achieving > > interoperability) from? Definitely not in RFC 2129. > > Why were you looking in 2129? :) Nevertheless I was right that SHOULD is not defined the way you described in "RFC2129" :-) Kidding aside, you are right I had a typo. It should be RFC 2119. That's where SHOULD is defined as I quoted. Alper > > As I said earlier when you want to ensure interoperability, you > typically use a "MUST". "SHOULD" means there is a probably that it is > not implemented and you don't have an interoperable implementation. > > Vijay > > > > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that > > the > > definition is an absolute requirement of the specification. > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that > > there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > > > > > Alper > > > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >> Sent: Monday, September 10, 2007 6:17 PM > >> To: Alper Yegin > >> Cc: 'Narayanan, Vidya'; 'Sri Gundavelli'; 'Julien Laganier'; > >> netlmm@ietf.org > >> Subject: Re: [netlmm] Issue: Auth Option support > >> > >> Alper, > >> > >> When we need to ensure interoperability, we use "MUST" and not > "SHOULD". > >> > >> Vijay > >> > >> Alper Yegin wrote: > >>> For interop "SHOULD implement and use", or even "SHOULD use" (like > >> Julien > >>> explained) is fine. "SHOULD" means "you better know what you are doing > >> if > >>> you don't follow", and that's exactly the case. > >>> > >>> If both ends are using some other mechanism and they know what each > >> other > >>> supports, they should not have to worry about (and implement) the > >> mechanism > >>> in the base spec. This is what SHOULD is for. > >>> > >>> Alper > >>> > >>> > >>>> -----Original Message----- > >>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>>> Sent: Friday, September 07, 2007 10:27 PM > >>>> To: Sri Gundavelli; Julien Laganier; netlmm@ietf.org > >>>> Subject: RE: [netlmm] Issue: Auth Option support > >>>> > >>>> All, > >>>> On this topic, I believe we must have a mandatory to implement > >> mechanism > >>>> specified for standards track publication. We can leave the use at > >>>> "RECOMMENDED" or "SHOULD", but, we need a "MUST" on what the LMA and > >> MAG > >>>> need to implement. > >>>> > >>>> I had run this by the security directorate at the Chicago meeting and > >> my > >>>> understanding is that as long as we have "MUST implement IPsec" and > >>>> "SHOULD use IPsec", it would be fine. > >>>> > >>>> In other words, the SHOULD vs. MUST that we want to place on using > >> IPsec > >>>> can be discussed, but, the "MUST" on implementation is non- > negotiable. > >>>> > >>>> This is inline with my understanding on what we need to state for a > >>>> complete specification. Given that channel security of signaling > >>>> messages is mandatory, unless we have at least one common denominator > >>>> that the MAG and LMA implementors will implement, we cannot ensure > >>>> interoperability. If they support multiple common mechanisms and > chose > >>>> to use something other than IPsec, that's fine - hence, the "SHOULD" > on > >>>> usage. > >>>> > >>>> Hope that helps. > >>>> > >>>> Thanks, > >>>> Vidya > >>>> > >>>>> -----Original Message----- > >>>>> From: Sri Gundavelli [mailto:sgundave@cisco.com] > >>>>> Sent: Friday, September 07, 2007 10:10 AM > >>>>> To: 'Julien Laganier'; netlmm@ietf.org > >>>>> Subject: RE: [netlmm] Issue: Auth Option support > >>>>> > >>>>> Hi Julien, > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: julien laganier [mailto:julien.laganier@gmail.com] On > >>>>> Behalf Of > >>>>>> Julien Laganier > >>>>>> Sent: Friday, September 07, 2007 5:29 AM > >>>>>> To: netlmm@ietf.org > >>>>>> Cc: Sri Gundavelli; 'Alper Yegin' > >>>>>> Subject: Re: [netlmm] Issue: Auth Option support > >>>>>> > >>>>>> Hi Sri, > >>>>>> > >>>>>> On Thursday 06 September 2007, Sri Gundavelli wrote: > >>>>>>> I'm confused, should the draft say > >>>>>>> > >>>>>>> "Both LMA and MAG MUST implement IPsec" and "all the signaling > >>>>>>> messages SHOULD be protected using IPSec". > >>>>>>> > >>>>>>> Will this ok, when reviewed by the security folks ? > >>>>>>> > >>>>>>> or mandate IPsec for this specification and let other draft relax > >>>>>>> this in the presence of an alternative approach ? > >>>>>>> > >>>>>>> Please comment. > >>>>>> Somehow, "MUST implement" and "SHOULD use" together seems a bit > >>>>>> tautologic. > >>>>>> > >>>>>> To me "SHOULD use" is sufficient since it covers both of the two > >>>>>> possibles cases: > >>>>>> > >>>>>> - deployment follows the SHOULD recommendation, it uses IPsec to > >>>>>> protect PMIPv6, in which case it supports it, since it's > >>>>> using it :), > >>>>>> or > >>>>>> > >>>>>> - deployment ignores the SHOULD recommendation, does not > >>>>> uses IPSec, > >>>>>> in which case it is useless to implement it since it's not used... > >>>>>> > >>>>>> I'd prefer having "MUST protect integrity of signalling > >>>>> messages, and > >>>>>> SHOULD use IPsec ESP to protect integrity of those messages". > >>>>>> We might > >>>>>> also add "MAY use IPsec AH". > >>>>>> > >>>>> I agree. I'm not against allowing other approaches. I'm only > >>>>> concerned, if we can leave the draft saying, "MUST protect > >>>>> integrity of signalling messages", with out specifying IPsec > >>>>> or some other approach. If that will pass the security > >>>>> review. We may have to state that IPsec MUST be used or some > >>>>> other approach, say Auth-Option MUST be used. Not sure, if we > >>>>> can leave this blank. > >>>>> > >>>>> Sri > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> netlmm mailing list > >>>>> netlmm@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>>>> > >>>> _______________________________________________ > >>>> netlmm mailing list > >>>> netlmm@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/netlmm > >>> > >>> _______________________________________________ > >>> netlmm mailing list > >>> netlmm@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/netlmm > > > > _______________________________________________ netlmm mailing list netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm
- [netlmm] (no subject) LAI, SHOU WEN -HCHBJ
- RE: [netlmm] Issue: Auth Option support Alper Yegin
- RE: [netlmm] Issue: Auth Option support Sri Gundavelli
- [netlmm] (no subject) Christian Vogt
- [netlmm] Re: your mail Sri Gundavelli
- [netlmm] Issue: Auth Option support Sri Gundavelli
- RE: [netlmm] Issue: Auth Option support Alper Yegin
- Re: [netlmm] Issue: Auth Option support Christian Vogt
- Re: [netlmm] Issue: Auth Option support Vijay Devarapalli
- RE: [netlmm] Issue: Auth Option support Chowdhury, Kuntal
- RE: [netlmm] Issue: Auth Option support Sri Gundavelli
- Re: [netlmm] Issue: Auth Option support Alexandru Petrescu
- RE: [netlmm] Issue: Auth Option support Alper Yegin
- Re: [netlmm] Issue: Auth Option support Alexandru Petrescu
- Re: [netlmm] Issue: Auth Option support Julien Laganier
- Re: [netlmm] Issue: Auth Option support Alexandru Petrescu
- Re: [netlmm] Issue: Auth Option support Julien Laganier
- Re: [netlmm] Issue: Auth Option support Alexandru Petrescu
- RE: [netlmm] Issue: Auth Option support Sri Gundavelli
- RE: [netlmm] Issue: Auth Option support Narayanan, Vidya
- Re: [netlmm] Issue: Auth Option support Basavaraj Patil
- RE: [netlmm] Issue: Auth Option support Sri Gundavelli
- Re: [netlmm] Issue: Auth Option support Basavaraj Patil
- Re: [netlmm] Issue: Auth Option support Vijay Devarapalli
- RE: [netlmm] Issue: Auth Option support Sri Gundavelli
- RE: [netlmm] Issue: Auth Option support Alper Yegin
- Re: [netlmm] Issue: Auth Option support Julien Laganier
- RE: [netlmm] Issue: Auth Option support Ahmad Muhanna
- RE: [netlmm] Issue: Auth Option support Ahmad Muhanna
- Re: [netlmm] Issue: Auth Option support Vijay Devarapalli
- Re: [netlmm] Issue: Auth Option support Vijay Devarapalli
- Re: [netlmm] Issue: Auth Option support Vijay Devarapalli
- RE: [netlmm] Issue: Auth Option support DE JUAN HUARTE FEDERICO
- RE: [netlmm] Issue: Auth Option support Ahmad Muhanna
- RE: [netlmm] Issue: Auth Option support Alper Yegin
- RE: [netlmm] Issue: Auth Option support Alper Yegin
- Re: [netlmm] Issue: Auth Option support Vijay Devarapalli
- [netlmm] Question on security model DE JUAN HUARTE FEDERICO
- RE: [netlmm] Question on security model Sri Gundavelli
- [netlmm] RE: Question on security model Ahmad Muhanna
- Re: [netlmm] Question on security model Julien Laganier
- RE: [netlmm] Question on security model Alper Yegin
- [netlmm] (no subject) Lynoh MaGee