Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt

From: [email-masked]
Date: Tue, 29 Jul 2003 20:52:37 -0500

Hi Acee,

The only thing we need is to have the source and destination addresses of the virtual link end points be predictable. I was told that the order of the IP addresses in the intra-area prefix LSA is not predictable. So choosing the first address will not provide us a deterministic address. Moreover, the order might change without bringing the virtual link down in which case the security rule will not match the packets. So we decided to choose the smallest address instead of the first one.

I don't know the intricacies of OSPF. So please correct me if I am wrong.

Are you suggesting that choosing the first address with LA-bit set in the intra-area prefix LSA "with the numerically lowest Link-State ID" will be more efficient than "choosing the smallest address with LA-bit set" ? 

regards
Mukesh

> -----Original Message-----
> From: ext Acee Lindem [mailto:[email-masked]]
> Sent: Tuesday, July 29, 2003 1:51 PM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt
> 
> 
> [email-masked] wrote:
> > Here is the change log:
> >
> > - Mandate using the "smallest" prefix with "LA-bit" set as
> >   the source and destination addresses for the packets
> >   exchanged over the virtual links if the security is
> >   enabled.
> 
> Hi Mukesh,
> 
> I think choosing the first address with the LA-bit set in
> the intra-area prefix LSA (router ref-LSA-type) with the
> numerically lowest Link-State ID is more efficient, easier for
> both sides to implement, and gives the OSPFv3 implementation
> greater freedom to influence the choice of a stable address
> to be used for the Virtual Link endpoint.
> 
> What are the arguments for making this change? It could be possible
> that I'm missing something :^) However, I think the dynamics are
> similar of handling virtual link endpoints are similar with
> both techniques.
> 
> Thanks,
> Acee
> 
> >
> > - Added IPsec requirements section
> >
> > - References divided in Normative and Informative
> >
> > - Some editorial changes
> >
> > - Some formatting errors corrected
> >
> > regards
> > Mukesh
> >
> >
> >>-----Original Message-----
> >>From: ext [email-masked] [mailto:[email-masked]]
> >>Sent: Tuesday, July 29, 2003 9:15 AM
> >>To: [email-masked]
> >>Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt
> >>
> >>
> >>A New Internet-Draft is available from the on-line
> >>Internet-Drafts directories.
> >>This draft is a work item of the Open Shortest Path First IGP
> >>Working Group of the IETF.
> >>
> >>        Title           : Authentication/Confidentiality for OSPFv3
> >>        Author(s)       : M. Gupta, N. Melam
> >>        Filename        : draft-ietf-ospf-ospfv3-auth-02.txt
> >>        Pages           : 8
> >>        Date            : 2003-7-29
> >>
> >>This document describes means/mechanisms to provide
> >>authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension
> >>Header.
> >>
> >>A URL for this Internet-Draft is:
> >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-a
uth-02.txt
>>
>>To remove yourself from the IETF Announcement list, send a message to
>>ietf-announce-request with the word unsubscribe in the body
>>of the message.
>>
>>Internet-Drafts are also available by anonymous FTP. Login
>>with the username
>>"anonymous" and a password of your e-mail address. After logging in,
>>type "cd internet-drafts" and then
>>        "get draft-ietf-ospf-ospfv3-auth-02.txt".
>>
>>A list of Internet-Drafts directories can be found in
>>http://www.ietf.org/shadow.html
>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>>        [email-masked].
>>In the body type:
>>        "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-02.txt".
>>
>>NOTE:   The mail server at ietf.org can return the document in
>>        MIME-encoded form by using the "mpack" utility.  To use this
>>        feature, insert the command "ENCODING mime" before the "FILE"
>>        command.  To decode the response(s), you will need
>>"munpack" or
>>        a MIME-compliant mail reader.  Different
>>MIME-compliant mail readers
>>        exhibit different behavior, especially when dealing with
>>        "multipart" MIME messages (i.e. documents which have
>>been split
>>        up into multiple messages), so check your local
>>documentation on
>>        how to manipulate these messages.
>>
>>
>>Below is the data which will enable a MIME compliant mail reader
>>implementation to automatically retrieve the ASCII version of the
>>Internet-Draft.
>
>
>

--
Acee

---

From: Michael J Barnes <[email-masked]>
Date: Tue, 29 Jul 2003 22:03:57 -0700

Hi Mukesh,

> Are you suggesting that choosing the first address with LA-bit set in the intra-area prefix LSA "with the numerically lowest Link-State ID" will be more efficient than "choosing the smallest addres…

I agree with Acee. To address your concern, a smart implementation will not
allow the address to be unnecessarily changed (e.g. the same address with
LA-bit set will be put at the beginning of the first intra-area prefix LSA
unless there's a good reason to change it), so the virtual link will not flap
unnecessarily.

Regards,
Michael

---

From: Acee Lindem <[email-masked]>
Date: Wed, 30 Jul 2003 01:45:40 -0400

Hi Mukesh and Micheal,

Michael J Barnes wrote:
>> The only thing we need is to have the source and destination addresses
>> of the virtual link end points be predictable. I was told that the
>> order of the IP addresses in the intra-area prefix LSA is not
>> predictable. So choosing the first address will not provide us a
>> deterministic address.

I think allowing the implementation to select most stable address (for
example, always preferring loopbacks) and making the first LA-bit
set prefix in the first (or only) intra-area prefix LSA is a better
strategy.

>  Moreover, the order might change without
>> bringing the virtual link down in which case the security rule will
>> not match the packets. So we decided to choose the smallest address
>> instead of the first one.

I don't see that this buys that much. An OSPFv3 implementation will
need to detect a change in an intra-area prefix LSA. At this time
it should also determine whether or not the endpoint LA-bit enabled
address changes. The implementation will need to handle the case
where it changes no matter what selection algorithm is used.

>> Are you suggesting that choosing the first address with LA-bit set in
>> the intra-area prefix LSA "with the numerically lowest Link-State ID"
>> will be more efficient than "choosing the smallest address with LA-bit
>> set" ?

Yes. I believe it is easier to parse prefixes in the first LSA and stop
when you find one with the LA bit enabled than it is to go through all the
prefixes in potentially multiple LSAs looking for the numerically
smallest.

> unless there's a good reason to change it), so the virtual link will not

Agreed.

One more point - I really don't see why the virtual link has to flap as
long as the endpoint gets the updated intra-area prefix LSA prior to
router dead timeout.

--
Acee