Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01

From: Sriganesh Kini <[email-masked]>
Date: Tue, 29 Mar 2011 11:49:56 -0400

Just an FYI to the list

This draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 was presented at the OSPF WG mtg today.

Thanks for the comments/questions at the mic. We will submit a new version addressing the comments.

Note that the other drafts related to Fast Notification (FN) are draft-lu-fn-transport and draft-lu-fast-notification-framework. These were presented in RTGWG.

Thanks

- Sri

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 29 Mar 2011 17:45:59 -0700

Dear Authors,
please kindly consider my comments and questions below (though some could be
duplicates of already received):

   - section 4.3 Fast Flooding has reliability as first requirement. I've
   noticed that Section 4 Operation doesn't list Auto-discovery or Registration
   as part of Fast Failure Notification mechanism. Is it assumed that an IGP
   will build the list of addressees, participants of the Fast Notification?
   - how would node(s) that detected a failure would achieve reliable
   transport of notifications?
   - if full set of destinations is not known what indicates that
   notification reached all participants?
   - when requiring reliability of notification transport you consider
   "notification received" or "notification processed"
   - section 5.2 I believe that in the scenario you present not only node B
   will flood notifications, but node A will flood them as well. That would not
   change convergence time if only to improve it in some scenarios but it might
   be worth to mention that notifications will be generated by both ends of a
   failed link.

Regards,
Greg

On Tue, Mar 29, 2011 at 8:49 AM, Sriganesh Kini <[email-masked]
> wrote:

> Note that the other drafts related to Fast Notification (FN) are
> draft-lu-fn-transport and draft-lu-fast-notification-framework. These were
> presented in RTGWG.
>
> Thanks
>
> - Sri
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>
>

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 29 Mar 2011 23:17:12 -0700

inline

On Tue, Mar 29, 2011 at 5:45 PM, Greg Mirsky <[email-masked]> wrote:
> section 4.3 Fast Flooding has reliability as first requirement. I've noticed
> that Section 4 Operation doesn't list Auto-discovery or Registration as part
> of Fast Failure Notification mechanism. Is it assumed that an IGP will build
> the list of addressees, participants of the Fast Notification?
> how would node(s) that detected a failure would achieve reliable transport
> of notifications?

This is through capability advertisement. It was in the -00 but was
erroneously omitted in -01. Will be re-added.

> if full set of destinations is not known what indicates that notification
> reached all participants?
> when requiring reliability of notification transport you consider

There is no ack for FN. Redundancy is achieved by using redundant
trees. OSPF Flooding ensures consistency in the worst case.

> section 5.2 I believe that in the scenario you present not only node B will
> flood notifications, but node A will flood them as well. That would not

That depends on the failure and its detection. It will only improve
things and has been mentioned in the related drafts.

>
> Regards,
> Greg
>
> On Tue, Mar 29, 2011 at 8:49 AM, Sriganesh Kini
> <[email-masked]> wrote:
>>
>> Just an FYI to the list
>>
>> This draft
>> http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 was
>> presented at the OSPF WG mtg today.
>>

-- 
- Sri

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 30 Mar 2011 13:24:36 +0530

Hi Sri,

This is regarding the point that i had raised yesterday - If the routers flood the "LSAs" in the data plane without verifying them, then we're leaving a hole open for DoS attacks, as any packet masquerading as a legitimate OSPF packet will get flooded on all routers. This is different from data packets flooding as these packets will be occupying the higest priority queues in both the ingress, egress and the CPU.

Second, what happens if the control packet is carrying an OSPF authentication digest? Would you still flood it without verifying the contents or would those be flooded regardless? I guess, you said that it would be the former. If thats the case, then this is not easy to do it in the HW as you would (i) need to parse the OSPF payload first to determine that its carrying a digest (ii) you would then need to verify it, which means you would be running HMAC-SHA in HW on the packet (given the Apad stuff that we have added in RFC5709 i dont think you can easily do this in HW) (iii) once the digest is verified you would need to flood it out on all the valid OSPF interfaces.

Cheers, Manav
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sriganesh Kini
Sent: Tuesday, March 29, 2011 9.20 PM
To: [email-masked]
Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01

Just an FYI to the list

Thanks

- Sri

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 30 Mar 2011 02:45:19 -0700

Hi Manav, see inline

On Wed, Mar 30, 2011 at 12:54 AM, Bhatia, Manav (Manav)
<[email-masked]> wrote:
> Hi Sri,
>
> This is regarding the point that i had raised yesterday - If the routers
> flood the "LSAs" in the data plane without verifying them, then we're
> leaving a hole open for DoS attacks, as any packet masquerading as a
> legitimate OSPF packet will get flooded on all routers. This is different
> from data packets flooding as these packets will be occupying the higest
> priority queues in both the ingress, egress and the CPU.

Control pkts (not restricted to FN) though given high priority, the
good implementations use throttling mechanisms to prevent (D)DoS.
Root-causing of related alarms is also a high priority operational
procedure.

>
> Second, what happens if the control packet is carrying an OSPF
> authentication digest? Would you still flood it without verifying the
> contents or would those be flooded regardless? I guess, you said that it
> would be the former. If thats the case, then this is not easy to do it in
> the HW as you would (i) need to parse the OSPF payload first to determine
> that its carrying a digest (ii) you would then need to verify it, which
> means you would be running HMAC-SHA in HW on the packet (given the Apad
> stuff that we have added in RFC5709 i dont think you can easily do this in
> HW) (iii) once the digest is verified you would need to flood it out on all
> the valid OSPF interfaces.

What I said is that verification before flooding is also an option we
have considered (see draft-lu-fn-transport for details). In our
prototyping experience the overhead of verifying auth in HW was not
much. However we do recognize that this may not be true with all HW
and all auth methods. It may introduce more delays in FN delivery in
some architectures and implementations. So forwarding without
verifying could get better convergence times at the expense of the
invalid FN packet reaching more nodes. If a platform is capable of
verifying without introducing a lot of delay then it should definitely
do it and such a platform can mitigate the problem in the network
where other platforms may not verifying before forwarding.

-- 
- Sri

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 30 Mar 2011 17:34:53 +0530

Hi Wenhu,

I never asserted they would - If you claim to do auth verification in HW then you would presumably take care of this as well.

I'm saying that either ways you have an issue.

Cheers, Manav

________________________________
From: Wenhu Lu [mailto:[email-masked]]
Sent: Wednesday, March 30, 2011 5.31 PM
To: Bhatia, Manav (Manav); Sriganesh Kini
Cc: [email-masked]
Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01

Hi Manav,
How would the data-plane auth verification prevent such DoS attacks?
Any replayed packets will go through.

Thanks,
-wenhu

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Wednesday, March 30, 2011 12:55 AM
To: Sriganesh Kini
Cc: [email-masked]
Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01

Hi Sri,

Cheers, Manav

Just an FYI to the list

Thanks

- Sri

---

From: Wenhu Lu <[email-masked]>
Date: Wed, 30 Mar 2011 08:07:50 -0400

Hi Manav,

Thanks,
-wenhu

Hi Sri,

Cheers, Manav

Just an FYI to the list

Thanks

- Sri

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 30 Mar 2011 17:46:21 +0530

Hi Sri,

> Root-causing of related alarms is also a high priority operational

I agree that all implementations rate limit all kinds of traffic, but you would concede that limiting is much less aggressive for network control (NC) packets. This also means that a bunch of illegitimate NC packets will actually affect the genuine NC traffic - so you could on certain platforms see 10ms BFD flaps because theres a flood of data-plane forwarded LSAs. 

Most QoS scheduling algorithms would drain the NC queue first before getting to the other (BE, AF, etc) queues. While the algorithm could change (strict scheduling, WFQ, etc) the end result would still be the same, where NC packets would *affect* other queues/traffic. Thus my point is that we should be extremely circumspect with any proposal that unabashedly floods control traffic.

> and all auth methods. It may introduce more delays in FN delivery in

I can say with a very high degree of confidence that most, if not all, ASIC based silicons will not be able to do the HMAC-SHA kind of authentication verification that has been proposed in RFC 5310, RFC 5709, RFC 4822 and scores of other IETF routing drafts on BFD, LDP, etc.

> invalid FN packet reaching more nodes. 

.. and potentially flapping BFD and other control plane protocols.

> If a platform is capable of

Yes, but that cant happen today.

Cheers, Manav

---

From: Wenhu Lu <[email-masked]>
Date: Wed, 30 Mar 2011 08:21:26 -0400

Hi Manav,
If I read it correctly, your original message said there would be a hole if we don't do verification in data plane. Now you are saying you never asserted it would, I'm confused.
As Sri mentioned, the rate limiting should solve the problem easily.

Thanks,
-wenhu

________________________________
From: Bhatia, Manav (Manav) [mailto:[email-masked]]
Sent: Wednesday, March 30, 2011 5:05 AM
To: Wenhu Lu; Sriganesh Kini
Cc: [email-masked]
Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01

Hi Wenhu,

Cheers, Manav

Hi Manav,

Thanks,
-wenhu

Hi Sri,

Cheers, Manav

Just an FYI to the list

Thanks

- Sri

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 30 Mar 2011 17:59:21 +0530

Hi Wenhu,

I am trying to say this:

If you dont do verification in HW then you leave a hole open for DoS, which means that you MUST do verification before flooding. However, this is easier said than done, and its extremely complex and convoluted to do this in HW.

And this is precisely why i had said "I'm saying that either ways you have an issue." in my last mail that you responded to.

Cheers, Manav
Sent: Wednesday, March 30, 2011 5.51 PM

Hi Manav,

Thanks,
-wenhu

Hi Wenhu,

Cheers, Manav

Hi Manav,

Thanks,
-wenhu

Hi Sri,

Cheers, Manav

Just an FYI to the list

Thanks

- Sri

---

From: Wenhu Lu <[email-masked]>
Date: Wed, 30 Mar 2011 09:10:53 -0400

Hi Manav,

Verification in HW would mean more than auth check. One will have to move seq number check and lot of ospf logic into hardware, which as you said is extremely complex. We tried to avoid this.
As for the said DoS attacks, in fact, any attackers can send OSPF packets directly to an OSPF router and squeeze off its normal good packets. This is a common problem in the IP routing, not specific to this draft.
And this is also the reason that network designers are cautious not to let their network be facing the subscribers directly.

Regards,
-wenhu

Sent: Wednesday, March 30, 2011 5:29 AM

Hi Wenhu,

I am trying to say this:

Cheers, Manav

Hi Manav,

Thanks,
-wenhu

Hi Wenhu,

Cheers, Manav

Hi Manav,

Thanks,
-wenhu

Hi Sri,

Cheers, Manav

Just an FYI to the list

Thanks

- Sri

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 30 Mar 2011 19:54:20 +0530

Right but there is a big difference - Today, if somebody inundates a router with OSPF packets, its just this router that gets affected. With your proposal, since all these packets will get flooded, all the other routers would get affected as well. In addition, it will also affect the data traffic as described earlier. So, there is quite a bit of difference in the two cases.

Cheers, Manav

Sent: Wednesday, March 30, 2011 6.41 PM

Hi Manav,

Regards,
-wenhu

Hi Wenhu,

I am trying to say this:

Cheers, Manav

Hi Manav,

Thanks,
-wenhu

Hi Wenhu,

Cheers, Manav

Hi Manav,

Thanks,
-wenhu

Hi Sri,

Cheers, Manav

Just an FYI to the list

Thanks

- Sri

---

From: Wenhu Lu <[email-masked]>
Date: Thu, 31 Mar 2011 19:21:57 -0400

FYI the authors and Manav had a good hall way talk and it turned out that we need some clarifications:
1. the fast-notification is a special packet created and sent upon certain events such as a link breakage. The normal ospf packets like hello, dd, lsa will go as is and will not be "fast-flooded".
2. the special fn packets can be either a newly defined packet format, or just an LSA but with a pre-defined multicast group address MC-FN (c.f. draft) which is different than regular OSPF group addresses.
3. Only fn packets will be put on and flooded through the said multicast trees. Other type of packets will not.
4. The dampening mechanism will be placed in the forwarding plane to prevent the potential DoS attacks.

We plan to update our draft to a newer version which will include more clarifications.
We thank Manav and others for many constructive comments and questions.
In the meanwhile, we welcome and solicit more comments and suggests and we will incorpate them into the next revision.

Thank you,
-wenhu

Hi Wenhu,

I am trying to say this:

Cheers, Manav

Hi Manav,

Thanks,
-wenhu

Hi Wenhu,

Cheers, Manav

Hi Manav,

Thanks,
-wenhu

Hi Sri,

Cheers, Manav

Just an FYI to the list

Thanks

- Sri