Subject: [karp] OSPFv3 Auth - Packet Prioritization

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 19 Jun 2010 09:00:40 +0530

Hi,

Since OSPFv3 uses IPSec (when doing authentication) it becomes very difficult to prioritize certain control packets. I believe this should too get addressed in any document that discusses OSPF. 

Cheers, Manav

--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India

---

From: mark Brown <[email-masked]>
Date: Sun, 20 Jun 2010 19:39:23 +0530

If i understand your comment then you're saying that because OSPFv3
uses IPSec, that somehow affects its ability to prioritize certain
OSPFv3 packets. If this is correct then would be great if you can
elaborate on this.

Mark

On Sat, Jun 19, 2010 at 9:00 AM, Bhatia, Manav (Manav)
<[email-masked]> wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 20 Jun 2010 10:37:15 -0400

There have been multiple debates about this question.
Given that the OSPF stack knows what SPI it is using, and knows that it 
is using authentication without encryption, it is actually possible in 
most implementations to set up suitable prioritization filters.  It is 
harder than it would be without IPSec, sinc ethe fields are in different 
places.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 20 Jun 2010 10:40:15 -0400

I do want to make two related points here:
1) I did a presentation  at NANOG about our work.  From talking with the 
operators there, the critical deliverable is actually the ability to 
change keys.  Make things work more securely is nice, but being able to 
easily and smoothly change keys is what they want.

2) We need to distinguish between implications based on particular 
implementation strategies, and implications inherent in the protocol. 
The later are things we need to address.  The former are things we 
should keep an eye on (simpler implementations tend to be more accurate 
and robust), but can not be the make or break issue for the WG.

Yours,
Joel M. Halpern

PS: The second concern I heard at the meeting is one that the WG can not 
directly address.  The operators are concerned that if we change the 
security mechanisms, the vendors will give them broken implementations.

---

From: Venkatesh Sriram <[email-masked]>
Date: Mon, 21 Jun 2010 04:59:35 +0530

This doesnt look very clean - on a scaled setup where there are
O(1000) different OSPF sessions, one would have to install the same
order of prioritization filters to prioritize the hellos and the acks.
If a unique filter is required for each hello and ack (and which would
certainly be the case), then this would mean that number of filters is
double the number of sessions.

Affably,
Sriram

On Sun, Jun 20, 2010 at 8:07 PM, Joel M. Halpern <[email-masked]> wrote:
> Given that the OSPF stack knows what SPI it is using, and knows that it is
> using authentication without encryption, it is actually possible in most
> implementations to set up suitable prioritization filters.  It is harder
> than it would be without IPSec, sinc ethe fields are in different places.
>
> Yours,
> Joel
>
> mark Brown wrote:
>>
>>> Since OSPFv3 uses IPSec (when doing authentication) it becomes very
>>> difficult to prioritize certain control packets. I believe this should too
>>> get addressed in any document that discusses OSPF.
>>>
>>> Cheers, Manav
>>>
>>> --
>>> Manav Bhatia,

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 20 Jun 2010 16:45:19 -0700

Hi folks,

Just to add another aspect to the discussion.

DSCP value can be part of the criteria to select the SA to use. It is
reccomended to use different SA's for different priorities, otherwise
sequence number checks can cause valid packets to be discarded.

Thanks,
Vishwas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 20 Jun 2010 19:45:41 -0400

?
While OSPF can support more than 1,000 devices, it is VERY rare to have 
s situation in which a single device has naything like that number of 
adjacencies.  (NBMA networks tend to large numbers of adjacencies, but 
not that large.)

Exactly how you make this work is very implementation dependent.  THere 
are likely to be some implementations where it is difficult.

Yours,
Joel

---

From: Bill Atwood <[email-masked]>
Date: Sun, 20 Jun 2010 20:53:01 -0400

Having lived through the disk arm scheduling era and having discovered
at that time that "priority for responding to a disk request really
doesn't matter, because the queue depth is seldom greater than one", I
am motivated to ask a basic question about prioritization for OSPF packets.

It seems from the current discussion that the designers of OSPF have
stated a priority for handling incoming routing packets.

Given that many neighbor relationships are in the form of "two OSPF
routers share a LAN", and that the delivery of packets on that LAN is
unlikely to have any priority attached to it (especially if the LAN is
Ethernet-based)

AND given that the scheduling of routing packet handling will depend on
the scheduling of the routing process on the router (which will probably
happen each time that a routing packet arrives, rather than waiting for
"n" packets to be accumulated)

THEN I believe that it is possible that no effective prioritization of
routing packets will be in effect.

So the question is the following:

Does anyone have any measurements, on real routers with substantial
loads, of the average number of packets that a prioritization mechanism
would have to choose from at a particular instant?

If this number is significantly greater than one, then I would agree
that the WG needs to worry about prioritization.  If it is less than
one, then we need to state the case as to why prioritization is not
important, and tell people that using IPsec (with no special treatment
for priorities) is "just fine".

Does anyone have any data?  If so, are you willing to share it?

  Bill

On 6/20/2010 10:37 AM, Joel M. Halpern wrote:
>>> difficult to prioritize certain control packets. I believe this
>>> should too get addressed in any document that discusses OSPF.
>>>
>>> Cheers, Manav
>>>
>>> -- 
>>> Manav Bhatia,

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email: [email-masked]
1455 de Maisonneuve Blvd. West    http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 20 Jun 2010 18:16:12 -0700

Hi Bill,

Have a look at
http://tools.ietf.org/html/draft-ietf-ospf-scalability-05. It should
have the data. I know the details got removed when this got published
as an RFC.

Thanks,
Vishwas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Jun 2010 01:05:33 -0400

That document, while it has recommendations, does not hav ethe data that 
Bill asked for.

Further, that document talks about prioritization of processing, and 
overload of CPU and Memory.  Given that such processing does not require 
line card assistance, or careful queueing between line cards and the 
control processor, that can clearly be done in conjunction with OSPFv3 
authentication.

Yours,
Joel M. Halpern

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 20 Jun 2010 22:26:29 -0700

Joel,

In my experience when we have to get packets sent to CPU from the
ASIC, you can program priorities of different kinds of packets, or do
it for all packets.

By doing it with the kind of packets, it certainly helps scale the
protocol processes. We have seen this with a lot of protocols and not
just OSPF.

If I understood right Bill's question probably was how prioritization
helps with OSPF and how it works with IPsec and data? I remember
working on this when writing the draft.

http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Chung-EnterpriseQoS-final.pdf
is a link to Enterprise QoS which talks about some things that may be
relevent to the discussion.

Thanks,
Vishwas

On Sun, Jun 20, 2010 at 10:05 PM, Joel M. Halpern <[email-masked]> wrote:
> line card assistance, or careful queueing between line cards and the control
> processor, that can clearly be done in conjunction with OSPFv3
> authentication.
>
> Yours,
> Joel M. Halpern
>
> Vishwas Manral wrote:
>>
>> Hi Bill,
>>
>> Have a look at

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 22 Jun 2010 04:43:32 +0530

Hi Bill,

> "n" packets to be accumulated)

Unfortunately its always the latter that happens on any live router deployed in the field. There are many tasks/processes running on a router which are contending for CPU cycles and it is never guaranteed that OSPF will always get scheduled and get CPU slice each time it gets a packet. This means that all OSPF packets will get queued till OSPF gets a chance to pick them up for further processing. Further, even if OSPF gets scheduled there will be some delay (and this is really getting deep into the implementation, however it more or less remains true for most implementations) in draining packets out of its queue as it could be involved in doing something else (processing expired timer events, processing the packet that was just drained, running SPF, etc).

> for priorities) is "just fine".

It will always be more than one from my experience. Assume you are doing a database (DD) exchange (or one of your neighbors refreshed its entire LSDB) with some routers while you already have some OSPF adjacencies that are up. There is a very high chance that your HELLO from one of your neighbors gets stuck in a queue sandwiched between the high number of DD packets that are in your queue. There are various implementation tricks employed to get around such issues and almost all carrier grade routers that I have designed and worked on will do something to prioritize these HELLOs so that our adjacencies don't time out in such scenarios.

So, prioritization is a real issue and cannot be overlooked.

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 22 Jun 2010 04:48:59 +0530

Hi Vishwas,

We could but this wouldn't really help us prioritizing certain routing protocol packets, as all routing packets would have the same DSCP value (NC) set.

Cheers, Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vishwas Manral
> Sent: Monday, June 21, 2010 5.15 AM
> To: Venkatesh Sriram
> Cc: [email-masked]
> Subject: Re: [karp] OSPFv3 Auth - Packet Prioritization
> 
> Hi folks,
>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 21 Jun 2010 16:57:27 -0700

Hi Manav,

> We could but this wouldn't really help us prioritizing certain routing protocol packets, as all routing packets would have the same DSCP value (NC) set.
Not necessary.

Thanks,
Vishwas

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 22 Jun 2010 06:18:32 +0530

Hmm .. I have never heard of assigning a different DSCP values between OSPF packets and I don't even think this is correct. Egress Qos in most router implementations would typically look at the DSCP or the dot1p values before assigning the appropriate per port egress queue. If different packets are assigned different DSCP values then there is a chance that the packets with the lower DSCP (AF, BE, etc) values may get dropped at the egress. Clearly, we would not want that. I would thus believe that all control traffic would get NC, unless explicitly configured by the user for something else.

Cheers, Manav

> From: Vishwas Manral [mailto:[email-masked]] 
> Sent: Tuesday, June 22, 2010 5.27 AM
> To: Bhatia, Manav (Manav)
> Cc: Venkatesh Sriram; [email-masked]
> > We could but this wouldn't really help us prioritizing 
> certain routing protocol packets, as all routing packets 
> would have the same DSCP value (NC) set.
> Not necessary.
> 
> Thanks,
> Vishwas
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 23 Jun 2010 04:48:11 +0530

Prioritizing OSPFv3 packets will always be a challenge as compared to OSPFv2. In the latter it is trivial for implementations to determine if the incoming packet is the one that needs to be prioritized or not (by looking at the OSPF packet type from the OSPF header). However, this becomes difficult in OSPFv3 since its using IPSec ESP. With OSPFv3 somebody could also use ESP with encryption (though I see no reason why anyone would want to do that) in which case the entire packet needs to be decrypted before an implementation can decide whether is a high priority packet or not. If we are decrypting all packets in sequence then we are NOT prioritizing packets. 

The second, and the more common case is when we are using ESP with a null cipher (integrity only). Even in this case implementations would have to install a per SPI filter to identify higher priority packets as the OSPF packet type field will end up at different offsets depending upon the negotiation between the two ends. This is because the IV carried in the ESP-NULL packet is optional and can be 0 or 8 bytes depending upon the data origination mechanism being used to protect the packets. Its generally 0, but can also be set to 8, if AES-GMAC is being used [RFC 4543]. We can, in future, have newer authentication algorithms that may need a different IV length.

One way to solve this is by using WESP [RFC 5840] for OSPFv3 so that implementations can install one or two global filters instead of the per SPI that needs to be done otherwise. 

Cheers, Manav

> Behalf Of Joel M. Halpern
> Sent: Monday, June 21, 2010 5.16 AM
> To: Venkatesh Sriram
> Cc: [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 23 Jun 2010 15:42:40 +0300

Bhatia, Manav (Manav) writes:
> Prioritizing OSPFv3 packets will always be a challenge as compared
> to OSPFv2. In the latter it is trivial for implementations to
> determine if the incoming packet is the one that needs to be
> prioritized or not (by looking at the OSPF packet type from the OSPF
> header). However, this becomes difficult in OSPFv3 since its using
> IPSec ESP. With OSPFv3 somebody could also use ESP with encryption
> (though I see no reason why anyone would want to do that) in which
> case the entire packet needs to be decrypted before an
> implementation can decide whether is a high priority packet or not.
> If we are decrypting all packets in sequence then we are NOT
> prioritizing packets.  

If those packets really need to use prioritization and the sender
knows which packets needs to be priorized then the easiest solution is
to create two IPsec SAs, one for low priority traffic and one for high
priority traffic. The sender can then put traffic on the appropriate
SA depending on the priority and the receiver can always prioritize
packets from the high priority SA.

This will also solve the sliding window problem as each of those SAs
do have separate windows, so lower priority packets are not thrown
away even when there is lots of high priority packets causing them to
be delayed.

This is standard IPsec RFC4301 behavior.

What is not yet standardized is for the receiver to detect which of
the SAs is the one sending high priority traffic, and which is for low
priority traffic. This is not needed for interoperability, thus it is
left out from the IPsec negotiation process.

Receiver can use whether means to find out which SA should be
prioritized (for example counting number of "high priority packets",
and if enough % of packets coming from an SA are high priority
packets, then it will mark that this SA should have high priority. 

> The second, and the more common case is when we are using ESP with a
> null cipher (integrity only). Even in this case implementations
> would have to install a per SPI filter to identify higher priority
> packets as the OSPF packet type field will end up at different
> offsets depending upon the negotiation between the two ends. This is
> because the IV carried in the ESP-NULL packet is optional and can be
> 0 or 8 bytes depending upon the data origination mechanism being
> used to protect the packets. Its generally 0, but can also be set to
> 8, if AES-GMAC is being used [RFC 4543]. We can, in future, have
> newer authentication algorithms that may need a different IV length. 
>
> One way to solve this is by using WESP [RFC 5840] for OSPFv3 so that
> implementations can install one or two global filters instead of the
> per SPI that needs to be done otherwise.

WESP is not really meant for that, as it is meant for middle nodes to
be able to detect the parameters. Here the OSPF recipient is the
end-node of the IPsec SA, thus it will know the parameters (like the
IV length) because it has negotiated them with the other end. There is
no need to use WESP or heuristics, as the device needing that
information will already know it.

SA information lookup based on the SPI is very cheap operation
compared to anything else that happening based on the packet, and it
is operation that MUST be done anyways for every single packet, thus
postponing it does not help.
-- 
[email-masked]

---

From: Acee Lindem <[email-masked]>
Date: Wed, 23 Jun 2010 18:21:57 -0400

Hi Manav,

The way to do this is for the originating OSPFv3 implementation to appropriately set the traffic class in the IPv6 header. Since OSPFv3 uses transport mode IPsec, the IPv6 header is not authenticated or encrypted. Hence, the lower layers in originating router, the receiving router(s), and any intermediate routers (for virtual links) can give these OSPFv3 packets  their due prioritization. 

Anyway, I didn't think confidentiality, i.e., encryption, was in the KARP charter. 

Thanks,
Acee

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 24 Jun 2010 05:29:15 +0530

Hi Acee,

The discussion was about prioritizing certain OSPFv3 packets (like the HELLOs, etc). Are you suggesting that such packets should be sent with a different traffic class?

Cheers, Manav 

> From: Acee Lindem [mailto:[email-masked]] 
> Sent: Thursday, June 24, 2010 3.52 AM
> Cc: Joel M. Halpern; Venkatesh Sriram; [email-masked]
> The way to do this is for the originating OSPFv3 
> implementation to appropriately set the traffic class in the 
> IPv6 header. Since OSPFv3 uses transport mode IPsec, the IPv6 
> header is not authenticated or encrypted. Hence, the lower 
> layers in originating router, the receiving router(s), and 
> any intermediate routers (for virtual links) can give these 
> OSPFv3 packets  their due prioritization. 
> 
> > Prioritizing OSPFv3 packets will always be a challenge as 
> compared to OSPFv2. In the latter it is trivial for 
> implementations to determine if the incoming packet is the 
> one that needs to be prioritized or not (by looking at the 
> OSPF packet type from the OSPF header). However, this becomes 
> difficult in OSPFv3 since its using IPSec ESP. With OSPFv3 
> somebody could also use ESP with encryption (though I see no 
> reason why anyone would want to do that) in which case the 
> entire packet needs to be decrypted before an implementation 
> can decide whether is a high priority packet or not. If we 
> are decrypting all packets in sequence then we are NOT 
> prioritizing packets. 
> > 
> > The second, and the more common case is when we are using 
> ESP with a null cipher (integrity only). Even in this case 
> implementations would have to install a per SPI filter to 
> identify higher priority packets as the OSPF packet type 
> field will end up at different offsets depending upon the 
> negotiation between the two ends. This is because the IV 
> carried in the ESP-NULL packet is optional and can be 0 or 8 
> bytes depending upon the data origination mechanism being 
> used to protect the packets. Its generally 0, but can also be 
> set to 8, if AES-GMAC is being used [RFC 4543]. We can, in 
> future, have newer authentication algorithms that may need a 
> different IV length.
> > 
> > One way to solve this is by using WESP [RFC 5840] for 
> OSPFv3 so that implementations can install one or two global 
> filters instead of the per SPI that needs to be done otherwise. 
> > 
> > Cheers, Manav
> >

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 24 Jun 2010 05:45:19 +0530

> packets from the high priority SA.

Yup, this sounds like an acceptable solution. All HELLOs and ACKs could use one IPSec SA while the rest of the packets could go over the other. 

> away even when there is lots of high priority packets causing them to

The sliding window problem exists only for OSPFv2 and is not applicable to OSPFv3 as its turned off for manually keyed SAs.

Cheers, Manav

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 23 Jun 2010 17:43:52 -0700

Hi Manav,

The below is from my mail.
> sequence number checks can cause valid packets to be discarded.

I guess you are now agreeing to what I had said earlier.

> The sliding window problem exists only for OSPFv2 and is not applicable to OSPFv3 as its turned off for manually keyed SAs.
No, OSPFv3 and IPSec in particular is what is being talked about here.

Thanks,
Vishwas

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 24 Jun 2010 06:20:28 +0530

Hi Vishwas,

> I guess you are now agreeing to what I had said earlier.

No, I still don't agree to this - we cant have different DSCP values for different OSPFv3 packets. In the two IPSec SA approach all IP packets will still go out with the same DSCP or the traffic class values (and thus get the same egress QoS treatment). Its only at the receiving end that we will drain packets quickly out of the higher prio SA (which is what we desire).

> 
> > The sliding window problem exists only for OSPFv2 and is 
> not applicable to OSPFv3 as its turned off for manually keyed SAs.

But we will not be using any sequence numbers in IPSec for OSPFv3, so there is no sliding window to deal with!

Cheers, Manav

> > Yup, this sounds like an acceptable solution. All HELLOs 
> and ACKs could use one IPSec SA while the rest of the packets 
> could go over the other.
> >
> >>
> > The sliding window problem exists only for OSPFv2 and is 
> not applicable to OSPFv3 as its turned off for manually keyed SAs.
> >
> > Cheers, Manav

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 23 Jun 2010 17:54:48 -0700

Hi Manav,

This is funny.

>> and ACKs could use one IPSec SA while the rest of the packets
Low priority and high priority can have different DSCP value. :)) Just
think over it.

Thanks,
Vishwas

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 24 Jun 2010 06:31:55 +0530

Hi Vishwas,

I don't think we should change the DSCP values within OSPF (or any control protocol) as this can affect the QoS treatment that's given to these packets both at the egress of the sending router and the ingress of the receiving router. If I send a HELLO with a DSCP of NC and the port is congested it might still pass through. However, if the LSUpdate packet is with DSCP BE or AF then there are chances that it can get dropped. The same thing exists at the other end. I will not want this to happen.

I believe there is a subtle difference in how both of us think some packets should be prioritized over the others. 

Cheers, Manav

> Sent: Thursday, June 24, 2010 6.25 AM
> > No, I still don't agree to this - we cant have different 
> DSCP values for different OSPFv3 packets. In the two IPSec SA 
> approach all IP packets will still go out with the same DSCP 
> or the traffic class values (and thus get the same egress QoS 
> treatment). Its only at the receiving end that we will drain 
> packets quickly out of the higher prio SA (which is what we desire).
> 
> However you just said:
> > But we will not be using any sequence numbers in IPSec for 
> OSPFv3, so there is no sliding window to deal with!
> >
> > Cheers, Manav
> >
> >>
> >> Thanks,
> >> Vishwas
> >>

---

From: Acee Lindem <[email-masked]>
Date: Thu, 24 Jun 2010 07:34:51 -0400

Hi Manav,
Yes - this isn't done today but it seems like a more direct path than using a different authentication. Also, If we were to consider a different authentication mechanism for OSPFv3, I think we need to consider doing something more along the lines of OSPFv2 since IPsec has proved inadequate for routing protocols. 
Thanks,
Acee

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 24 Jun 2010 13:00:15 +0300

> Low priority and high priority can have different DSCP value. :)) Just

In most cases the when the IPsec and OSPF are not tightly combined
together the OSPF needs to somehow indicate to the IPsec that it
should use different SAs for these two different classes of OSPF
traffic. The easiest way to do that is to set them to have different
DSCP values, as DSCP aware IPsec implementations should already be
able to select SAs based on the DSCP values. 
-- 
[email-masked]

---

From: mark Brown <[email-masked]>
Date: Thu, 24 Jun 2010 21:04:14 +0530

Hey Acee,

Tero and Manav (and others) are not suggesting different
authentication algorithms for Hellos when they're alluding to
different IPSec SAs. The second SA is only being used so that IPSec
can prioritize packets arriving on one SA over the packets arriving on
the other. Folks please correct me if i am wrong.

Mark

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Jun 2010 10:33:59 -0700

Acee Lindem wrote:
> Hi Manav,
> Yes - this isn't done today but it seems like a more direct path than using a
> different authentication. Also, If we were to consider a different
> authentication mechanism for OSPFv3, I think we need to consider doing something
> more along the lines of OSPFv2 since IPsec has proved inadequate for routing
> protocols.

I'm confused by this discussion - few networks have different priorities for
handling control plane traffic.

This seems like an issue for the local edge. You really want two different
sockets so packets don't backup inside the router.

The number of SAs or DSCPs doesn't seem relevant.

Joe

---

From: Acee Lindem <[email-masked]>
Date: Thu, 24 Jun 2010 15:49:53 -0400

Hey Mark,

I knew that - what I'm saying is that since OSPFv3 uses transport mode IPsec, the originator could set the traffic class in the IPv6 header (not protected by IPsec) to influence prioritization. 

My second comment is that perhaps we made a mistake in using IPsec for OSPFv3 given the limitations. With RFC5709. we have stronger authentication in OSPFv2 and we could use similar mechanisms with OSPFv3. LLs (RFC5613) could be used to carry the authentication data. 

Thanks,
Acee

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 24 Jun 2010 12:58:07 -0700

Hi Joe,

Your intent is right. We do not want a backlog of packets in the OS
socket layer either.

However with the hardware based forwarders we need to also put the
packets in seperate queues there to be picked up by the software. This
is where DSCP can be used as a generic mechanism.

Thanks,
Vishwas

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Jun 2010 13:02:44 -0700

Hi, Vishal,

> is where DSCP can be used as a generic mechanism.

Dealing with implementation limitations is outside the scope of this WG, AFAICT.

This can be done with different SAs or different DSCPs, but ultimately it's an
implementation issue to be addressed, not a security issue.

Joe

---

From: Bill Atwood <[email-masked]>
Date: Thu, 24 Jun 2010 16:18:37 -0400

Well said.  All these approaches (DSCP, different SAs, etc.) exist in
current implementations.

What I take from all this discussion is that we should do nothing in our
design guidelines document or our framework document that would
_prevent_ using *any* of the implementation approaches.

  Bill

>>>>>>>>>>>> get addressed in any document that discusses OSPF.

- --

---

From: Sam Hartman <[email-masked]>
Date: Thu, 24 Jun 2010 16:43:50 -0400

Joe> Hi, Vishal,
    Joe> Vishwas Manral wrote:
    >> Hi Joe,
    >> 
    >> Your intent is right. We do not want a backlog of packets in the
    >> OS socket layer either.
    >> 
    >> However with the hardware based forwarders we need to also put
    >> the packets in seperate queues there to be picked up by the
    >> software. This is where DSCP can be used as a generic mechanism.

    Joe> Dealing with implementation limitations is outside the scope of
    Joe> this WG, AFAICT.

I've found that WGs that consider implementation realities are more
likely to get their protocols deployed.  So, if we have implementors
explaining that if we make one choice then their hardware can support
our approach, while if we make another choice it cannot, we should
consider that.  Similarly, we definitely should document approaches for
dealing with common implementation troubles both to confirm that it is
possible to implement and to increase interoperability.

Obviously, we should not get bogged down in implementation
details. Additionally, there are other factors besides implementation
simplicity.

However I definitely think implementation considerations should be in
scope.

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Jun 2010 13:44:37 -0700

> _prevent_ using *any* of the implementation approaches.

I wouldn't say *any*; I would say it should not prevent some *reasonable*
implementation approaches, or should be very clear if it does prevent some and why.

Joe

---

From: Bill Atwood <[email-masked]>
Date: Thu, 24 Jun 2010 16:52:41 -0400

> implementation approaches, or should be very clear if it does prevent some and why.

Absolutely!

  Bill

- --

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Jun 2010 14:10:24 -0700

Hi, Sam,

Agreed on all counts - implementation issues are important. However, here the
issue should be whether the implementation issue limits the security options. At
least one reasonable option should remain. It's OK, however, for other security
concerns to rule out some common implementation solutions that might be used
otherwise.

Joe