Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

From: Alan Davey <[email-masked]>
Date: Thu, 17 Feb 2011 11:50:24 +0000

Folks

I have read draft-ietf-ospf-auth-trailer-ospfv3-02 and have a few minor nits as follows.

-           After an unplanned graceful restart, a router may send Grace-LSAs in an LS Update packet before any Hello packets.  Unless I am missing something, the draft should include such LS Update packets in the list of those that MUST have the AT-bit set.

-          In Figure 1, for the packet on the left hand side, the IP Header Length HL = PL + LL (not PL + AL).

-          In section 4.1 Authentication Trailer, in the Auth type bullet, the following wording be clearer; "At present, the only value defined is 1, to denote ..."?

Regards
Alan Davey

Software Engineer, Network Technologies Division
Metaswitch Networks
[email-masked]<mailto:[email-masked]>
+44 (0) 20 8366 1177
www.metaswitch.com<http://www.metaswitch.com/>

---

From: Srinivasan K L <[email-masked]>
Date: Thu, 17 Feb 2011 20:02:46 +0530

Hi,

This question has set me thinking on the draft "Security Extension for
OSPFv2 when using Manual Key Management". When a router reboots, assuming
that it cannot remember the last sequence number it used, how will it start
re-establishing peers. Are the existing peers supposed to accept
(temporarily maybe, without losing the previous sequence number information
- anyway the challenge mechanism can protect against replay attacks) packets
with a new (lower) sequence number that pass authentication. Or will it take
RouterDeadInterval for the rebooted router to get accepted? In case it takes
RouterDeadInterval, unplanned GR cannot be supported, since the first
packets sent out will be grace LSAs, probably with lower (zero) sequence
numbers. I think this should be explicitly covered in the draft.

Regards,

Srini.

****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan
Davey
Sent: Thursday, February 17, 2011 5:20 PM
To: [email-masked]
Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

Folks

I have read draft-ietf-ospf-auth-trailer-ospfv3-02 and have a few minor nits
as follows.

-           After an unplanned graceful restart, a router may send
Grace-LSAs in an LS Update packet before any Hello packets.  Unless I am
missing something, the draft should include such LS Update packets in the
list of those that MUST have the AT-bit set.

-          In Figure 1, for the packet on the left hand side, the IP Header
Length HL = PL + LL (not PL + AL).

-          In section 4.1 Authentication Trailer, in the Auth type bullet,
the following wording be clearer; "At present, the only value defined is 1,
to denote ..."?

Regards

Alan Davey

 <mailto:[email-masked]> [email-masked]
+44 (0) 20 8366 1177
 <http://www.metaswitch.com/> www.metaswitch.com

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 17 Feb 2011 20:17:38 +0530

Hi Srini,

This problem is not unique to this solution. As per RFC 3623:

"The router may need to preserve the cryptographic sequence numbers being used on each interface in non-volatile storage.         An alternative is to use the router's clock for cryptographic sequence number generation and ensure that the clock is         preserved across restarts (either on the same or redundant route processors).  If neither of these can be guaranteed, it         can take up to RouterDeadInterval seconds after the restart before adjacencies can be reestablished and this would force         the grace period to be lengthened greatly."

Cheers, Manav
________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Srinivasan K L
	Sent: Thursday, February 17, 2011 8.03 PM
	To: 'Alan Davey'; [email-masked]
	Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

	Hi,

	This question has set me thinking on the draft "Security Extension for OSPFv2 when using Manual Key Management". When a router reboots, assuming that it cannot remember the last sequence number it used, how will it start re-establishing peers. Are the existing peers supposed to accept (temporarily maybe, without losing the previous sequence number information - anyway the challenge mechanism can protect against replay attacks) packets with a new (lower) sequence number that pass authentication. Or will it take RouterDeadInterval for the rebooted router to get accepted? In case it takes RouterDeadInterval, unplanned GR cannot be supported, since the first packets sent out will be grace LSAs, probably with lower (zero) sequence numbers. I think this should be explicitly covered in the draft.

	Regards,

	Srini.

	***************************************************************************************
	This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

	________________________________

		From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Davey
	Sent: Thursday, February 17, 2011 5:20 PM
	To: [email-masked]
	Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

	Folks

	Regards

	Alan Davey

	[email-masked] <mailto:[email-masked]> 
	+44 (0) 20 8366 1177
	www.metaswitch.com <http://www.metaswitch.com/>

---

From: Srinivasan K L <[email-masked]>
Date: Thu, 17 Feb 2011 20:31:14 +0530

Hi Manav,

With this new draft, since the sequence number MUST be strictly increasing,
I think using the clock may no longer be an option. Also, unplanned GR can
never be supported since at RouterDeadInterval, the rebooted router will be
declared down and there would be no use in processing the Grace LSAs after
that. Would this not be a significant restriction ? Maybe we can find a
solution for this too....

Regardsm
Srini. 

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Thursday, February 17, 2011 8:18 PM
To: Srinivasan K L; 'Alan Davey'; [email-masked]
Subject: RE: [OSPF] Supporting Authentication Trailer for OSPFv3

Hi Srini,

"The router may need to preserve the cryptographic sequence numbers being
used on each interface in non-volatile storage.         An alternative is to
use the router's clock for cryptographic sequence number generation and
ensure that the clock is         preserved across restarts (either on the
same or redundant route processors).  If neither of these can be guaranteed,
it         can take up to RouterDeadInterval seconds after the restart
before adjacencies can be reestablished and this would force         the
grace period to be lengthened greatly."

Cheers, Manav

	From: [email-masked] [mailto:[email-masked]] On Behalf
Of Srinivasan K L
	Sent: Thursday, February 17, 2011 8.03 PM
	To: 'Alan Davey'; [email-masked]
	Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

	Hi,

	This question has set me thinking on the draft "Security Extension
for OSPFv2 when using Manual Key Management". When a router reboots,
assuming that it cannot remember the last sequence number it used, how will
it start re-establishing peers. Are the existing peers supposed to accept
(temporarily maybe, without losing the previous sequence number information
- anyway the challenge mechanism can protect against replay attacks) packets
with a new (lower) sequence number that pass authentication. Or will it take
RouterDeadInterval for the rebooted router to get accepted? In case it takes
RouterDeadInterval, unplanned GR cannot be supported, since the first
packets sent out will be grace LSAs, probably with lower (zero) sequence
numbers. I think this should be explicitly covered in the draft.

	Regards,

	Srini.

****************************************************************************
***********
	This e-mail and attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

		From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alan Davey
	Sent: Thursday, February 17, 2011 5:20 PM
	To: [email-masked]
	Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

	Folks

	I have read draft-ietf-ospf-auth-trailer-ospfv3-02 and have a few
minor nits as follows.

	-          In Figure 1, for the packet on the left hand side, the IP
Header Length HL = PL + LL (not PL + AL).

	-          In section 4.1 Authentication Trailer, in the Auth type
bullet, the following wording be clearer; "At present, the only value
defined is 1, to denote ..."?

	Regards

	Alan Davey

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 17 Feb 2011 21:56:30 +0530

Hi Srini,

While 3623 alludes to using a clock to generate the seq number, I don't think we should, as the clock can go back in time, which can disrupt OSPF routing. 

There is no change in the crypto sequence number mechanism in this draft and we will be able to do GR similar to how its done for OSPFv2.

Cheers, Manav

> From: Srinivasan K L [mailto:[email-masked]] 
> Sent: Thursday, February 17, 2011 8.31 PM
> To: Bhatia, Manav (Manav); 'Alan Davey'; [email-masked]

---

From: Acee Lindem <[email-masked]>
Date: Thu, 17 Feb 2011 11:45:12 -0500

Hi Srini,
The fact that graceful restart will be more difficult is part of the cost of implementing this draft. One of the jobs of the OSPF WG is determining whether the "medicine is worse than the disease". In this case, the disease is well-timed replay attacks and the medicine is the proposed solution. 
Thanks,
Acee 
On Feb 17, 2011, at 10:01 AM, Srinivasan K L wrote:

> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 17 Feb 2011 22:18:01 +0530

Arent we mixing this draft with draft-bhatia-karp-ospf-ip-layer-protection-03?

If not, then I don't see why AT will create any new problems for GR?

Cheers, Manav 

> From: Acee Lindem [mailto:[email-masked]] 
> Sent: Thursday, February 17, 2011 10.15 PM
> To: Srinivasan K L
> Cc: Bhatia, Manav (Manav); Alan Davey; [email-masked]
> The fact that graceful restart will be more difficult is part 
> of the cost of implementing this draft. One of the jobs of 
> the OSPF WG is determining whether the "medicine is worse 
> than the disease". In this case, the disease is well-timed 
> replay attacks and the medicine is the proposed solution. 
> Thanks,
> Acee

---

From: Acee Lindem <[email-masked]>
Date: Thu, 17 Feb 2011 11:50:44 -0500

Hi Srini,

---

From: Acee Lindem <[email-masked]>
Date: Thu, 17 Feb 2011 13:33:00 -0500

Hi Alan,

> -           After an unplanned graceful restart, a router may send Grace-LSAs in an LS Update packet before any Hello packets.  Unless I am missing something, the draft should include such LS Updat…

The options are not included in the LS Update packet. However, if the restarting router was using the authentication restart before the restart, it should use it afterwards and the helping neighbor adjacencies should reflect this fact. 

> -          In Figure 1, for the packet on the left hand side, the IP Header Length HL = PL + LL (not PL + AL).

Right - this will be included in the 03 version.

> -          In section 4.1 Authentication Trailer, in the Auth type bullet, the following wording be clearer; “At present, the only value defined is 1, to denote ...”?

Ok - I'll reword this in the 03 version as well. 

Thanks,
Acee

> [email-masked]
> +44 (0) 20 8366 1177
> www.metaswitch.com
>  
>

---

From: Srinivasan K L <[email-masked]>
Date: Fri, 18 Feb 2011 10:26:06 +0530

Hi Manav,

While I too am not so keen on using the clock, it must be admitted that
using the clock is a "cheap" way of generating non-decreasing sequence
numbers. Given that clock changes will not be frequent, it can be argued
that this is ok. But the new draft rules this possibility out completely by
mandating the use of strictly increasing sequence numbers. So while GR
will/can work by the existing mechanism, the new draft makes it difficult.
So it may be better to give a solution for this too.

BTW, can you please explain how rollover of the sequence number is expected
to be handled in the new draft?

Thanks,
Srini.

P.S> Have changed the "subject" ;-)

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Thursday, February 17, 2011 9:57 PM
To: Srinivasan K L; 'Alan Davey'; [email-masked]
Subject: RE: [OSPF] Supporting Authentication Trailer for OSPFv3

Hi Srini,

While 3623 alludes to using a clock to generate the seq number, I don't
think we should, as the clock can go back in time, which can disrupt OSPF
routing. 

There is no change in the crypto sequence number mechanism in this draft and
we will be able to do GR similar to how its done for OSPFv2.

Cheers, Manav

> =

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 18 Feb 2011 10:49:45 +0530

Hi Srini,

Ok, so now were NOT discussing the Authentication Trailer draft! Thanks for clearing the confusion!

> numbers. Given that clock changes will not be frequent, it 

I don't think it's a reasonable to use a clock for generating sequence numbers citing the reason that clock changes will not be frequent. Even if it changes once the router does become vulnerable to attacks.

> can be argued

The existing GR mechanism will only work if you can somehow remember your last sequence number. If you have the ability to do that then you can easily increment your sequence number the next time you come up.

> to be handled in the new draft?

There are two proposals in the draft now.

One uses the nonce and the session ID and the other uses the 64 bit crypto sequence. Lets first look at the latter, as that's much easier. 

When the router reboots, the most significant 4 bytes would increase by one and the helpers will accept the packets as they'll come with a seq number that's higher than what they have. In this case we don't even need the restriction that's currently placed in 3623 about preserving the sequence number across restarts. 

In case the WG decides to go by the nonce/session ID mechanism then we could add a note saying that the restarting router must preserve its FIB and other state information, such as the grace period, nonce, session ID and cryptographic sequence number for an interface, across the restart. 

I am not a big fan of preserving too much state across restarts and we can also think of mechanisms by which the restarting router need not preserve its nonce and session ID info across restarts. However, lets only spend time on this once we have some clarity on the approach the WG wants to take. If the WG decides to go by the expanded cryptographic sequence space then we don't need to worry about this.

We will also add a note on the graceful restart mechanism in the next version of the draft.

Cheers, Manav

---

From: Srinivasan K L <[email-masked]>
Date: Fri, 18 Feb 2011 12:21:14 +0530

Hi Acee,

I am a little confused here. Quoting from the draft:

2.1.  AT-Bit in Options Field
 
   A new AT-bit (AT stands for Authentication Trailer) is introduced
   into the OSPFv3 Options field.  OSPFv3 routers MUST set the AT-bit in
   OSPFv3 Hello and Database Description packets to indicate that the
   OSPFv3 router will include the authentication trailer in all OSPFv3
   packets on the link.  For OSPFv3 Hello and Database Description
   packets, the AT-bit indicates the AT is present.  For other OSPFv3
   packet types, the OSPFv3 AT bit setting is preserved from the OSPFv3
   Hello/Database Description setting.

The last line above says that the bit setting must be preserved from the
hello/dd. Does this not mean that the bit will be set in the LS Update
containing the Grace LSA? I do understand that the restarting router must
remember that AT was used or not before and then set/clear it accordingly.

Regards,

Srini.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Friday, February 18, 2011 12:03 AM
To: Alan Davey
Cc: [email-masked]
Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

Hi Alan,

Folks

The options are not included in the LS Update packet. However, if the
restarting router was using the authentication restart before the restart,
it should use it afterwards and the helping neighbor adjacencies should
reflect this fact. 

Thanks,

Acee

Regards

Alan Davey

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 18 Feb 2011 12:28:25 +0530

Hi Srini,

In OSPFv3 the Options field is present only in the Hellos and the DD packets, hence you cannot set the AT bit in the LS Update packet containing the Grace LSAs. The helping router would know that AT has been negotiated with the restarting router and MUST hence look for the AT block.

Cheers, Manav

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Srinivasan K L
Sent: Friday, February 18, 2011 12.21 PM
To: 'Acee Lindem'; 'Alan Davey'
Cc: [email-masked]
Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

Hi Acee,

The last line above says that the bit setting must be preserved from the hello/dd. Does this not mean that the bit will be set in the LS Update containing the Grace LSA? I do understand that the restarting router must remember that AT was used or not before and then set/clear it accordingly.

Regards,
Srini.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem
Sent: Friday, February 18, 2011 12:03 AM
To: Alan Davey
Cc: [email-masked]
Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

Hi Alan,

Folks

Thanks,
Acee

Regards
Alan Davey

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: Srinivasan K L <[email-masked]>
Date: Fri, 18 Feb 2011 12:33:35 +0530

Hi Manav,

Got it, thanks.

Regards,

Srini.

  _____  

From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Friday, February 18, 2011 12:28 PM
To: Srinivasan K L; 'Acee Lindem'; 'Alan Davey'
Cc: [email-masked]
Subject: RE: [OSPF] Supporting Authentication Trailer for OSPFv3

Hi Srini,

In OSPFv3 the Options field is present only in the Hellos and the DD
packets, hence you cannot set the AT bit in the LS Update packet containing
the Grace LSAs. The helping router would know that AT has been negotiated
with the restarting router and MUST hence look for the AT block.

Cheers, Manav

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Srinivasan K L
Sent: Friday, February 18, 2011 12.21 PM
To: 'Acee Lindem'; 'Alan Davey'
Cc: [email-masked]
Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

Hi Acee,

 

Regards,

Srini.

  _____  

Hi Alan,

Folks

 

Thanks,

Acee

 

Regards

Alan Davey

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 23 Feb 2011 23:10:27 -0500

In message <[email-masked]>
Acee Lindem writes:
>  
> Hi Srini,
>  
> The fact that graceful restart will be more difficult is part of the
> cost of implementing this draft. One of the jobs of the OSPF WG is
> determining whether the "medicine is worse than the disease". In this
> case, the disease is well-timed replay attacks and the medicine is the
> proposed solution.
>  
> Thanks,
> Acee

Acee, et al.

I hope no one minds that I trimmed the rest of the context.

It should be possible to on startup negociate a new initial sequence
number through an exchange that involves the exchange of an encrypted
or authenticated challenge using a shared key.  This would involve
additional protocol exchange which is in neither of the security
drafts being considered, but either could be changed.

Do so would allow the replay attack problem to be addressed without
creating a new problem due to forgetting the last sequence number that
was used after a gracefull restart wakeup.

If we are going to go to this extent, adding a negociation step, then
you might also want to add an option to exchange an encrypted session
key to avoid an attack where enough "in the clear" information is
authenticated to guess the key in use.

I can barely keep up with IETF email so I'd rather someone else pick
this idea up if its thought to be a good idea (maybe it isn't).  Now
back to lurking.

Curtis