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

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

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
________________________________
From: Wenhu Lu [mailto:[email protected]]
Sent: Wednesday, March 30, 2011 5.51 PM
To: Bhatia, Manav (Manav); Sriganesh Kini
Cc: [email protected]
Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01

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 protected]]
Sent: Wednesday, March 30, 2011 5:05 AM
To: Wenhu Lu; Sriganesh Kini
Cc: [email protected]
Subject: RE: [OSPF] FYI on draft-kini-ospf-fast-notification-01

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 protected]]
Sent: Wednesday, March 30, 2011 5.31 PM
To: Bhatia, Manav (Manav); Sriganesh Kini
Cc: [email protected]
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 protected] [mailto:[email protected]] On Behalf Of Bhatia, 
Manav (Manav)
Sent: Wednesday, March 30, 2011 12:55 AM
To: Sriganesh Kini
Cc: [email protected]
Subject: Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01

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 protected] [mailto:[email protected]] On Behalf Of 
Sriganesh Kini
Sent: Tuesday, March 29, 2011 9.20 PM
To: [email protected]
Subject: [OSPF] FYI on draft-kini-ospf-fast-notification-01

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
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to