Subject: [OSPF] WG Last Call for OSPF Link-local Signaling - draft-ietf-ospf-lls-04.txt

From: Acee Lindem <[email-masked]>
Date: Fri, 15 Feb 2008 12:15:01 -0500

This starts the WG last call for the subject document. The target  
status is Proposed Standard.
The WG last call will begin today and will end March 1st, 2008 at  
12:00 AM EST. Note that a previous revision (not including OSPFv3) of  
this protocol extension was published as an experimental RFC 4813.

Thanks,
Acee 
_______________________________________________
OSPF mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ospf

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 15 Feb 2008 09:41:53 -0800

Hi Acee,

I like the generic mechanism talked about in the document. I however
think the document does not describe how to treat TLV's if a TLV is
not understood. If you see all other newer specs for example RFC5036
for LDP, you will notice they have the first 2 bits defining how to
treat a packet if there is an unknown TLV.

The document says the block can only be attached to Hello and DD
packets, I would prefer the signaling to be able to be attached to any
packets. Thus making OSPF packets truly extensible.

The document talks about not doing a checksum if the Crytographic
security is present. I think it enhances security as well as
simplifies code if we calculate the checksum in all cases. Also the
document seems to think that MD5 is the only cryptographic
authentication method present and explicitly mentions it. The same
needs to be removed. Infact if we hear the view on MD5 it is closer
to:

* Use of MD5, ciphers with a strength of 56 bits or less should be
avoided in almost all circumstances. Use of ciphers with key sizes of
64 bits or less should be discontinued as soon as is practicable.

quoting from a mail in the SAAG list.

Also as routers that do not understand LLS may receive the packets, we
have to make sure to state that we need to take care changes made due
to LLS block TLV's do not affect the basic routing when interacting
with non-LLS routers. This will be a helpful guidance for any future
extensions to LLS TLV's.

Thanks,
Vishwas

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Fri, 15 Feb 2008 12:41:02 -0600

Hi Acee,
 
Generally, the draft looks useful/good.  One question: TLVs 32768-65535 are marked for Private Use -- what is the method for distinguishing the meaning for these TLVs when two different implementations utilize the same Private Use TLV?  Should OUI be placed in the first 3 octets? If so, can the I-D capture this?
 
Thanks,
 
Jonathan Sadler

________________________________

From: [email-masked] on behalf of Acee Lindem
Sent: Fri 2/15/2008 11:15 AM
To: OSPF List
Subject: [OSPF] WG Last Call for OSPF Link-local Signaling -draft-ietf-ospf-lls-04.txt

Thanks,
Acee

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
_______________________________________________
OSPF mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Fri, 15 Feb 2008 14:11:26 -0500

Hi Vishwas,

I suppose I should let the authors respond first but here are my  
thoughts (speaking as a WG member).

> treat a packet if there is an unknown TLV.

LLS is optional so the TLVs should have no impact on whether or not  
the OSPF packet itself is accepted. The document probably should state:

    1) That the described TLVs MUST be supported.
    2) What to do if an unknown TLV is encountered. The choices are:
        a. Simply ignore it - this is what people have implemented.
        b. Ignore the whole LLS block
        c. Ignore the whole LLS block contingent on the type encoding

I vote for a.

> packets. Thus making OSPF packets truly extensible.

I think that since this is "Link-Local" signaling, hello and DD  
packets make the most sense. In fact, at one time I had argued to  
limit it to hellos but the authors said there were cases where  
appending the signaling to the next DD would result in the signaling  
being communicated faster. However, since a hello can safely be sent  
at any time, I still feel limiting it to hello would be better :^).

> simplifies code if we calculate the checksum in all cases.

This is consistent to what is done for OSPF cryptographic  
authentication for the packet itself. I see no reason not to do the  
same for LLS or to effectively checksum it twice when authentication  
is configured.

> Also the

Agree - it should be written to cover further authentication mechanisms.

> with non-LLS routers. This will be a helpful guidance for any future

A statement along these lines should be included as well.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Fri, 15 Feb 2008 14:32:15 -0500

Hi Jonathan,
You've pointed out what I see as a problem with many experimental and  
private IANA ranges. I agree with the solution you suggest is what  
should be done - the vendor code should be required as the first 4  
octets of the value field in TLVs in the experimental/vendor range.  
This is also consistent with other OSPF IANA ranges defined in RFC 4940.
Thanks,
Acee

On Feb 15, 2008, at 1:41 PM, Sadler, Jonathan B. wrote:

> Hi Acee,
>
> Generally, the draft looks useful/good.  One question: TLVs  
> 32768-65535 are marked for Private Use -- what is the method for  
> distinguishing the meaning for these TLVs when two different  
> implementations utilize the same Private Use TLV?  Should OUI be  
> placed in the first 3 octets? If so, can the I-D capture this?
>
> Thanks,
>
> Jonathan Sadler
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 15 Feb 2008 11:37:22 -0800

Hi Acee,

>         c. Ignore the whole LLS block contingent on the type encoding
By having this we are forcing a behavior on future TLV's, they all
have to be optionally understood. We cannot enforce a behavior of drop
a packet if the TLV is not understood. By using the first 2 bits of
the TLV's to signal this behavior we could get such behavior for the
future. In my view such signalling may be possible in the future.

>  at any time, I still feel limiting it to hello would be better :^).
I do not see a reason to not allow LLS to packets other than Hello and
DD. Its all about future extensibility here. We should try to be
future proof by allowing the same. If a TLV is not expected in a
packet it can anyway be ignored.

>  same for LLS or to effectively checksum it twice when authentication
I agree it is consistent. I however see no benefits in the approach, though
I can point out problems with it. If we are making a new standard we could
as well rectify the same.

Thanks,
Vishwas

---

From: Acee Lindem <[email-masked]>
Date: Sun, 17 Feb 2008 21:31:50 -0500

Hi Vishwas,

On Feb 15, 2008, at 2:37 PM, Vishwas Manral wrote:

> a packet if the TLV is not understood.

You're missing the point that LLS is optional. There will be routers  
that don't support LLS that will process packets independent of what  
TLVs that are sent. Hence, there shouldn't be OSPF routers that  
understand LLS that drop the OSPF packet contingent on not  
understanding an LLS TLV.

> By using the first 2 bits of

This doesn't come for free. What types of things do you see LLS being  
used to signal on the other packet types? The same or different as  
hello and DD? This is for one hop signaling.

> I can point out problems with it.

Ok - what are they? A cryptographic HMAC hash is likely to be  
stronger than the standard inet checksum. The only advantage I can  
see is that you'll know the when there is a checksum error rather  
than an authentication failure. IMHO, doing both just for this  
advantage isn't a very good engineering trade-off at all. Sort of  
like taking both a bath and a shower on the hopes you might get a  
little cleaner.

Acee

> If we are making a new standard we could

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 18 Feb 2008 09:35:39 -0800

Hi Acee,

> understanding an LLS TLV.
I agree LLS is currently  optional, but like the Optional Opaque LSA
functionality, it will become an important part of most functionality.
One of the main issues I note about OSPF is that the packets and
information elements are not scalable, unlike TLV based protocols. I
think LLS mitigates this limitation.

> hello and DD? This is for one hop signaling.
All OSPF packets are one hop signaled, unlike IS-IS, where the same
LSP needs to be flooded through the domain.

> like taking both a bath and a shower on the hopes you might get a
Actually the currently known attacks in MD5 are done using keeping
some fields as constant (like say some fields in the packet which will
lead to the undesired behavior) and trying all random combinations of
the other fields to get the same value of Hash. This however will not
be possible for the Checksum field, as any random combination will not
qualify for a valid checksum.

That said I am ok, if we can leave the behavior as is.

Thanks,
Vishwas

---

From: Abhay Roy <[email-masked]>
Date: Mon, 18 Feb 2008 10:28:33 -0800 (PST)

Hi Vishwas,

Thanks for your comments. Please see inline:

> treat a packet if there is an unknown TLV.

Looking at some previous TLV usage in OSPF specs (e.g.
rfc3630), I think all we need to add is "Unrecognized TLV
types are ignored." I will add this text in section 2.3.

> packets. Thus making OSPF packets truly extensible.

Initially we only wanted it in Hello packets. But then we
found some use case for DD packets (rfc 4812). Sending LLS
with any packet type is technically feasible, but would
require separate documentation when such a need arises. I
would prefer to not include it in here at this time, since
there is no known use case.

> 64 bits or less should be discontinued as soon as is practicable.

I will remove direct references to MD5, so that it's equally 
applicable to any available cryptographic authentication.

> with non-LLS routers. This will be a helpful guidance for any future

Sure, I will add something to this effect..

Regards,
-Abhay

---

From: Liem Nguyen <[email-masked]>
Date: Mon, 18 Feb 2008 10:52:27 -0800

Hi Vishwas,

> LSP needs to be flooded through the domain.

Given that the Options field is primarily useful in Hello and DBD 
packets (which is required to convey
the presence of LLS block), I see no benefit in having LLS in other 
packet types.

Thanks,
Liem

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 18 Feb 2008 11:00:13 -0800

Hi Liem,

Like I gave the example of Opaque LSA's where we created an Opaque
mechanism which could be used for all packets, I envision that the LLS
would be a general mechanism to add additional information to the OSPF
header, just like Opaque LSA's allowed further information exchanged.

Thanks,
Vishwas

---

From: Liem Nguyen <[email-masked]>
Date: Mon, 18 Feb 2008 11:05:47 -0800

Hi Vishwas,

> header, just like Opaque LSA's allowed further information exchanged.

Thanks for the comments.
True, for Opaque.  But given that this is a link-local signaling 
mechanism, I don't foresee a need
where additional information can't be conveyed with either Hello or DBD 
packets.

Liem

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 18 Feb 2008 11:10:46 -0800

Hi Liem,

I would say its a difference of vision of where we see LLS heading to
between us. However in my view if we allow the functionality, we do
not create any new issues (besides of course any security issues which
may result), however extending this in the future would create issues
in the future.

Thanks,
Vishwas

---

From: Abhay Roy <[email-masked]>
Date: Mon, 18 Feb 2008 11:21:55 -0800 (PST)

Jonathan/Acee,

Thanks for your comments. We will add some text based on
rfc4940 on using vendor code to help distinguish them.

Regards,
-Abhay

On 02/15/08-0500 at 2:32pm, Acee Lindem writes:

> Hi Jonathan,
> You've pointed out what I see as a problem with many experimental and private 
> IANA ranges. I agree with the solution you suggest is what should be done - 
> the vendor code should be required as the first 4 octets of the value field 
> in TLVs in the experimental/vendor range. This is also consistent with other 
> OSPF IANA ranges defined in RFC 4940.
> Thanks,
> Acee
>
>> Generally, the draft looks useful/good.  One question: TLVs 32768-65535 are 
>> marked for Private Use -- what is the method for distinguishing the meaning 
>> for these TLVs when two different implementations utilize the same Private 
>> Use TLV?  Should OUI be placed in the first 3 octets? If so, can the I-D 
>> capture this?
>> 
>> Thanks,
>> 
>> Jonathan Sadler
>>

---

From: Liem Nguyen <[email-masked]>
Date: Mon, 18 Feb 2008 11:47:25 -0800

Hi Vishwas,

Yes, vision is getting more blurry at my age :-)
But back to this link local signaling, the other packet types
we are talking about are LS update/ack/req.
Do you really think we would need to provide additional
unique header information for these (BTW, we have none today)?
I understand the extensibility angle, but it doesn't seem warranted
in this case.

We may have to agree to differ.

Thanks,
Liem

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 18 Feb 2008 11:57:48 -0800

Hi Abhay/ Leim,

> > treat a packet if there is an unknown TLV.
I would think now that we have defined TLV's, we could add information
like first bit telling what to do with the packet (LLS part of the
packet) if the TLV is not .

I just noticed a draft in ISIS today (Multi Instance), which is using
a different set of addresses because there is no way in the TLV to
signal that in case you do not understand it drop the packet (and in
case of the wrong packet being communicated there will be issues). If
we had just had the bits in the TLV properly used in IS-IS we could
have a simple addition to make the thing work in all cases. It doesnt
spoil anything to do some work which may not create a problem for now,
but may be helpful in the future.

There are however other issues in IS-IS as the TLV type and length
fields are heavily constrained.

Thanks,
Vishwas

---

From: Abhay Roy <[email-masked]>
Date: Mon, 18 Feb 2008 12:12:12 -0800 (PST)

> packet) if the TLV is not .

Hmm.. TLV having bits on what to do with the packet? Given
that LLS is optional, I am afraid, it can't be used to have
policies which end up dropping the packet.

So I think we are OK with just adding the verbiage about
ignoring unknown TLVs.

> case of the wrong packet being communicated there will be issues).

ISIS is trying to add Instance ID's like OSPFv3 has. And
since it didn't have it from day one in the base packet
header, we came up with the IID TLV solution.

Regards,
-Abhay

> If we had just had the bits in the TLV properly used in
> IS-IS we could have a simple addition to make the thing
> work in all cases. It doesnt spoil anything to do some
> work which may not create a problem for now, but may be
> helpful in the future.
>
> There are however other issues in IS-IS as the TLV type
> and length fields are heavily constrained.
>
> Thanks,
> Vishwas
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 18 Feb 2008 12:17:52 -0800

Hi Abhay,

Yes, LLS is optional. However we can ask for behaviors like do not
look at the LLS packet itself if you do not recognize the TLV and we
will have optional behavior, by just using 1 bit (which anyway may not
have been used).

> header, we came up with the IID TLV solution.
Correct and they had to take the drastic measure of using a different
address. If they again have another feature where they do not want
connections to be formed for a particular TLV they will need another
address again. If they had just had a bit in the TLV to say, do not
look at the packet/ ignore the TLV if the TLV is unrecognized, the
behavior would just be adding a new TLV. This is very normal in most
new protocols - check the LDP RFC5036. Note that not much changes for
current implementations as such.

Thanks,
Vishwas

---

From: Abhay Roy <[email-masked]>
Date: Mon, 18 Feb 2008 13:07:42 -0800 (PST)

Hi Vishwas,

I am having hard time understanding the use case when one of
the "new" TLVs someone invents will ask all receivers to
stop process all the "old" TLVs. I propose we wait for
such innovations to come down the line v/s try to sneak
something in here at last call..

Also, lets take the ISIS discussion to isis working group..

Regards,
-Abhay

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 18 Feb 2008 13:40:55 -0800

Hi Abhay,

The IS-IS talk was just to learn lessons in OSPf from other protocols
which in this case is IS-IS.

Thanks,
Vishwas

---

From: Acee Lindem <[email-masked]>
Date: Tue, 19 Feb 2008 13:29:36 -0500

I agree.
Acee

---

From: Acee Lindem <[email-masked]>
Date: Mon, 25 Feb 2008 18:20:36 -0500

Hi Vishwas,

> future. In my view such signalling may be possible in the future.

LLS is a backward compatible extension. Hence, we're not dropping  
packets based on understanding TLVs.

> packet it can anyway be ignored.

I discussed this with on of the authors and if you are going to use  
LLS on other packet types, than it would probably be for a different  
set of things than we signal today. Hence, we're going to defer this  
until such signaling is required. I can't see putting this burden on  
the specification when we don't have a requirement.

Thanks,
Acee