Subject: [OSPF] AT Bit

From: Rajesh Shetty <[email-masked]>
Date: Wed, 19 Jan 2011 15:49:10 +0530

Dear All,

AT Bit Definition:

AT bit must be set in all ospfv3 protocol packets that contain an
authentication trailer. On the receiving side authentication trailer is only
examined if AT bit is set.

Consider a scenario where authentication trailer draft is supported by all
the routers and authentication is configured on receiving side but not on
sending side. Even in this scenario receiving side will successfully accept
the packet (Since AT bit is not set), this is a security threat.

Please correct me if I am missing something.

Thanks

Rajesh

 

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!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Friday, January 07, 2011 8:39 PM
To: Bhatia, Manav (Manav)
Cc: [email-masked]; Vishwas Manral
Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3

Actually I was just making sure everyone was paying attention :^) Since I'm
an author, I'll validate with Abhay and Stewart but I think we can move
forward and make this a WG document. 

Thanks, 

Acee 

On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote:

> I am sure Acee meant that the he and the authors would like to see this
draft adopted up as a WG draft.

> I agree with that sentiment and would request this to be accepted as a WG
document. We've had several mails in the past where this work was supported
and none that was against.

> Cheers, Manav

>> -----Original Message-----

>> From: Acee Lindem [mailto:[email-masked]] 

>> Sent: Friday, January 07, 2011 2.11 AM

>> To: [email-masked]

>> Cc: Bhatia, Manav (Manav); Vishwas Manral 

>> Subject: Supporting Authentication Trailer for OSPFv3 

>> Speaking as WG Co-Chair: 

>> At the last OSPF WG meeting, there was some interest in this 

>> draft. I'm now asking for opinions for and against. 

>> Speaking as a WG member: 

>> The authors (myself included) would not like to make this a 

>> WG draft. On the OSPF list and at the OSPF WG meeting, the 

>> only dissent was on along the lines of making IPsec 

>> (including IKEv2) work better with OSPFv3 rather than doing 

>> this. I don't disagree that this should be a goal but I don't 

>> think it should preclude this work. 

>> Thanks,

>> Acee

_______________________________________________

OSPF mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Wed, 19 Jan 2011 06:03:38 -0500

Hi Rajesh,

You are correct. I thought that this was in the draft but see that it is not. Right, we should drop packets with the AT Bit clear when authentication is configured on the receiving side. OSPFv3 will drop packets not containing the options field (LS-Request, LS-Update, and Ack) if the adjacency is not in Exchange state or higher. 

Thanks,
Acee
On Jan 19, 2011, at 5:19 AM, Rajesh Shetty wrote:

> Dear All,
>  
> AT Bit Definition:
> AT bit must be set in all ospfv3 protocol packets that contain an authentication trailer. On the receiving side authentication trailer is only examined if AT bit is set.
>  
> Consider a scenario where authentication trailer draft is supported by all the routers and authentication is configured on receiving side but not on sending side. Even in this scenario receiving side will successfully accept the packet (Since AT bit is not set), this is a security threat.
>  
> 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 Acee Lindem
> Actually I was just making sure everyone was paying attention :^) Since I'm an author, I'll validate with Abhay and Stewart but I think we can move forward and make this a WG document.
>  
>  
> Thanks,
> Acee
>  
> > I am sure Acee meant that the he and the authors would like to see this draft adopted up as a WG draft.
> >
> > I agree with that sentiment and would request this to be accepted as a WG document. We've had several mails in the past where this work was supported and none that was against.
> >
> > Cheers, Manav
> >

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 19 Jan 2011 17:35:27 +0530

Hi Acee,

I think the idea behind this logic was for the purposes of backward compatibility. I agree that this is not right if *all* routers support the AT capability. However, if you have even one router that does not support this, then you would probably need this mechanism.How would an implementation, that is AT incapable, send an OSPFv3 + LLS block to a router, if the receiving end always implicitly assumes the presence of an authentication trailer? One could argue that if the AT router has turned ON authentication then it MUST only accept packets with the AT block, but then we are taking a giant leap of faith where we're assuming that ALL routers will simultaneously turn on the AT mechanism.

 If folks think that this opens a security hole, then vendors could add a knob that could toggle this behavior. By default, the knob could assume the presence of an authentication trailer if auth has been turned on. The second state would be where authentication trailer is assumed to be present only if the AT bit is set.

If folks agree to this, then we could add a note about this in the next revision.

Cheers, Manav
________________________________
From: Acee Lindem [mailto:[email-masked]]
Sent: Wednesday, January 19, 2011 4.34 PM
To: Rajesh Shetty
Cc: Bhatia, Manav (Manav); [email-masked]
Subject: Re: [OSPF] AT Bit

Hi Rajesh,

Thanks,
Acee

Dear All,
AT Bit Definition:
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Acee Lindem
Sent: Friday, January 07, 2011 8:39 PM
To: Bhatia, Manav (Manav)
Cc: [email-masked]<mailto:[email-masked]>; Vishwas Manral
Subject: Re: [OSPF] Supporting Authentication Trailer for OSPFv3
Actually I was just making sure everyone was paying attention :^) Since I'm an author, I'll validate with Abhay and Stewart but I think we can move forward and make this a WG document.
Thanks,
Acee
On Jan 6, 2011, at 8:46 PM, Bhatia, Manav (Manav) wrote:
>> To: [email-masked]<mailto:[email-masked]>
_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Wed, 19 Jan 2011 08:27:24 -0500

Hi Manav,
Maybe I'm missing a key point but I think if you are using the new OSPFv3 authentication on a link then all routers on the network corresponding to that link need to support it in order to form adjacencies. 
Thanks,
Acee

---

From: Srinivasan K L <[email-masked]>
Date: Wed, 19 Jan 2011 19:30:32 +0530

Hi Manav,

I agree with Acee. Having a router that does not implement AT on a network
where other routers support AT will make that network vulnerable and defeat
the purpose of the draft itself. So maybe the question of compatibility does
not arise. It can be mandated that adjacencies should only be formed if the
AT bit matches the authentication setting on the interface.

Another problem: how can we ensure that a router that is incapable of
processing AT work correctly when receiving a packet from a router that is
sending both AT and LLS? In the current proposal, AT precedes LLS and so
older implementation will start interpreting AT as LLS and can be confused.

We may need to compromise consistency with OSPFv2 and recommend that AT
should come after LLS.

Regards,

Srini.

****************************************************************************
***********

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Wednesday, January 19, 2011 6:57 PM
To: Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: Re: [OSPF] AT Bit

Hi Manav,

Maybe I'm missing a key point but I think if you are using the new OSPFv3
authentication on a link then all routers on the network corresponding to
that link need to support it in order to form adjacencies. 

Thanks,

Acee

Hi Acee,

I think the idea behind this logic was for the purposes of backward
compatibility. I agree that this is not right if *all* routers support the
AT capability. However, if you have even one router that does not support
this, then you would probably need this mechanism.How would an
implementation, that is AT incapable, send an OSPFv3 + LLS block to a
router, if the receiving end always implicitly assumes the presence of an
authentication trailer? One could argue that if the AT router has turned ON
authentication then it MUST only accept packets with the AT block, but then
we are taking a giant leap of faith where we're assuming that ALL routers
will simultaneously turn on the AT mechanism.

 If folks think that this opens a security hole, then vendors could add a
knob that could toggle this behavior. By default, the knob could assume the
presence of an authentication trailer if auth has been turned on. The second
state would be where authentication trailer is assumed to be present only if
the AT bit is set. 

If folks agree to this, then we could add a note about this in the next
revision.

Cheers, Manav

  _____  

Hi Rajesh,

You are correct. I thought that this was in the draft but see that it is
not. Right, we should drop packets with the AT Bit clear when authentication
is configured on the receiving side. OSPFv3 will drop packets not containing
the options field (LS-Request, LS-Update, and Ack) if the adjacency is not
in Exchange state or higher.  

Thanks,

Acee

Dear All,

AT Bit Definition:

Thanks

Rajesh

-----Original Message-----

Thanks,

Acee

OSPF mailing list

[email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 19 Jan 2011 21:01:57 +0530

Hi Acee,

Thats correct. I was just thinking of a scenario where we might have a router that has not been upgraded to support AT yet, and wants to peer up with a router that does AT. One could envisage a setup where the old router would NOT do authentication, while all the newer ones would.

Cheers, Manav

________________________________
From: Acee Lindem [mailto:[email-masked]]
Sent: Wednesday, January 19, 2011 6.57 PM
To: Bhatia, Manav (Manav)
Cc: Rajesh Shetty; [email-masked]
Subject: Re: [OSPF] AT Bit

Hi Manav,

Hi Acee,

Cheers, Manav
Cc: Bhatia, Manav (Manav); [email-masked]<mailto:[email-masked]>

Hi Rajesh,

Thanks,
Acee

Dear All,
AT Bit Definition:

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 19 Jan 2011 21:08:26 +0530

Hi Srini,

>From the earlier discussion it seems that we will never mix AT capable and incapable routers. In such cases, the incapable router will never recieve an OSPF packet carrying the authentication trailer.

Cheers, Manav

________________________________
From: Srinivasan K L [mailto:[email-masked]]
Sent: Wednesday, January 19, 2011 7.31 PM
To: 'Acee Lindem'; Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: RE: [OSPF] AT Bit

Hi Manav,

I agree with Acee. Having a router that does not implement AT on a network where other routers support AT will make that network vulnerable and defeat the purpose of the draft itself. So maybe the question of compatibility does not arise. It can be mandated that adjacencies should only be formed if the AT bit matches the authentication setting on the interface.

Another problem: how can we ensure that a router that is incapable of processing AT work correctly when receiving a packet from a router that is sending both AT and LLS? In the current proposal, AT precedes LLS and so older implementation will start interpreting AT as LLS and can be confused.
We may need to compromise consistency with OSPFv2 and recommend that AT should come after LLS.

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!

Hi Manav,

Hi Acee,

Cheers, Manav

Thanks,
Acee

Dear All,
AT Bit Definition:

---

From: Michael Barnes <[email-masked]>
Date: Wed, 19 Jan 2011 09:47:58 -0800

Hi Manav,

I think that the authentication trailer should follow the LLS and should 
secure LLS as well as the other OSPF data. Even if an implementation 
doesn't want to completely support LLS, I think it is reasonable to 
require that in order to support the AT extension it can know how to 
find the AT when there is an LLS block.

I would also like to see this draft include similar Session ID and Nonce 
as defined in
draft-bhatia-karp-ospf-ip-layer-protection-01.txt although perhaps make 
it an optional feature.

Thanks,
Michael

On 01/19/2011 04:05 AM, Bhatia, Manav (Manav) wrote:
> compatibility. I agree that this is not right if *all* routers support
> the AT capability. However, if you have even one router that does not
> support this, then you would probably need this mechanism.How would an
> router, if the receiving end always implicitly assumes the presence of
> an authentication trailer? One could argue that if the AT router has
> turned ON authentication then it MUST only accept packets with the AT
> block, but then we are taking a giant leap of faith where we're assuming
> that ALL routers will simultaneously turn on the AT mechanism.
> knob that could toggle this behavior. By default, the knob could assume
> the presence of an authentication trailer if auth has been turned on.
> The second state would be where authentication trailer is assumed to be
> present only if the AT bit is set.

---

From: Michael Barnes <[email-masked]>
Date: Wed, 19 Jan 2011 09:50:34 -0800

Hi Manav,

On 01/19/2011 04:05 AM, Bhatia, Manav (Manav) wrote:
> One could argue that if the AT router has turned ON authentication then
> it MUST only accept packets with the AT block, but then we are taking a
> giant leap of faith where we're assuming that ALL routers will
> simultaneously turn on the AT mechanism.

Isn't it pointless to use authentication unless all of the devices 
support it?

Regards,
Michael

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 20 Jan 2011 05:21:40 +0530

Hi Michael,

The design was kept this way since this is how it is done in OSPFv2. Besides getting rid of IPsec the idea is also to bring OSPFv3 at par with OSPFv2 and we would like both the protocols to behave in a similar fashion. In v2, the Auth data precedes the LLS block and there is a separate TLV that carries authentication data for the LLS block. I think we should do the same for the sake of consistency between the two protocols.

The other idea behind putting AT before LLS was that if we did it the other way round, then implementations would NOT be able to support AT till they had at least minimal code that could understand and parse the LLS block. We didn't want that to happen as chances of seeing nodes supporting AT over LLS are higher.

I think we can include another subsection that defines a Cryptographic Authentication TLV for LLS that could be used for OSPFv3. Alternately, we could respin a one page draft that updates rfc 5613, and permits the existing crypto auth TLV to be used for OSPFv3 as well. I would personally prefer the latter approach as its cleaner to keep these things separate.

I don't think we should include the Session ID and Nonce here. That work will be done in KARP and it will take a looooooooong time before we finalize on a scheme that fixes OSPF authentication when using manual keying. Secondly, this draft is about bringing OSPFv3 auth at par with OSPFv2, since operators are using auth with v2 and are NOT doing it with v3. Implementing the AT draft is a matter of a few days, however, if you bring in the Session and the Nonce thing here, then we have already pushed it to a few years. I don't think we should wait for that long.

Cheers, Manav

> From: Michael Barnes [mailto:[email-masked]] 
> Sent: Wednesday, January 19, 2011 11.18 PM
> To: [email-masked]; Bhatia, Manav (Manav)
> Cc: Acee Lindem

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 20 Jan 2011 05:23:21 +0530

Hi Michael,

I agree, it is! :-)

I was just thinking of an incremental approach where not all routers have been upgraded with the new SW.

Cheers, Manav 

> Sent: Wednesday, January 19, 2011 11.21 PM

---

From: Michael Barnes <[email-masked]>
Date: Wed, 19 Jan 2011 16:58:42 -0800

> The design was kept this way since this is how it is done in OSPFv2. Besides getting rid of IPsec the idea is also to bring OSPFv3 at par with OSPFv2 and we would like both the protocols to behave…

OSPFv2 is the way it is because of the order in which features where 
introduced, in order to maintain backward compatibility, not because 
anyone thought this was the best way to authenticate LLS. I think we 
should not follow a precedence which is poor. IMHO the right way to do 
this for v3 is to have one authentication block for the OSPFv3 packet as 
well as the LLS block.

> The other idea behind putting AT before LLS was that if we did it the other way round, then implementations would NOT be able to support AT till they had at least minimal code that could understand…

I have a hard time believing that is a real issue. If the AT followed 
the LLS block, it would be pretty trivial find the length of the LLS 
block and calculate the position of the AT.

> I think we can include another subsection that defines a Cryptographic Authentication TLV for LLS that could be used for OSPFv3. Alternately, we could respin a one page draft that updates rfc 5613,…

I respectfully disagree.

> I don't think we should include the Session ID and Nonce here. That work will be done in KARP and it will take a looooooooong time before we finalize on a scheme that fixes OSPF authentication when…

If the fields are including in the initial definition, even if unused 
then it will ease implementation later. Let's please at least reserve 
space for them in the AT.

Thanks,
Michael

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 20 Jan 2011 06:45:28 +0530

Hi Michael,

> anyone thought this was the best way to authenticate LLS. I think we 

Yes.

> this for v3 is to have one authentication block for the 

I don't have a very strong opinion either ways. Would like to hear what others think about this.

> 
> > The other idea behind putting AT before LLS was that if we 
> did it the other way round, then implementations would NOT be 
> able to support AT till they had at least minimal code that 
> could understand and parse the LLS block. We didn't want that 
> to happen as chances of seeing nodes supporting AT over LLS 
> are higher.
> 

Which means that they would have to add minimal code to support understanding the "L" bit in the Options field and adding the parsing code so that they can reach the start of the AT.

> > I don't think we should include the Session ID and Nonce 
> here. That work will be done in KARP and it will take a 
> looooooooong time before we finalize on a scheme that fixes 
> OSPF authentication when using manual keying. Secondly, this 
> draft is about bringing OSPFv3 auth at par with OSPFv2, since 
> operators are using auth with v2 and are NOT doing it with 
> v3. Implementing the AT draft is a matter of a few days, 
> however, if you bring in the Session and the Nonce thing 
> here, then we have already pushed it to a few years. I don't 
> think we should wait for that long.
> 

Just reserving space for the Nonce and the Session ID in the AT may not be enough, as you would need to do something for your neighbors too. So, while we could reserve some space in the AT, that may still not be good enough when we get about fixing the manual keying for OSPFv3.

I suggest that we leave out these details now. If we make a good progress in the karp draft by the time this draft is ready for IESG we could certainly add the required fields as you have suggested. draft-bhatia-karp-ospf-ip-layer-protection is still an individual submission and I would not like to change things here based on what has been proposed there! 

Cheers, Manav

---

From: Srinivasan K L <[email-masked]>
Date: Thu, 20 Jan 2011 09:42:13 +0530

Hi Manav,

While it is expected that routers that support AT and that do not support AT
should not form adjacencies, that does not preclude the possibility that
they may physically share the same network. The other routers may also
running other protocols. My thought was just to ensure that these non-AT
supporting routers are not affected/confused by the new extension.

Regards,

Srini.

  _____  

From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Wednesday, January 19, 2011 9:08 PM
To: Srinivasan K L; 'Acee Lindem'
Cc: [email-masked]
Subject: RE: [OSPF] AT Bit

Hi Srini,

>From the earlier discussion it seems that we will never mix AT capable and
incapable routers. In such cases, the incapable router will never recieve an
OSPF packet carrying the authentication trailer. 

Cheers, Manav

  _____  

Hi Manav,

Regards,

Srini.

  _____  

Hi Manav,

Thanks,

Acee

Hi Acee,

Cheers, Manav

  _____  

Hi Rajesh,

Thanks,

Acee

Dear All,

AT Bit Definition:

Thanks

Rajesh

-----Original Message-----

Thanks,

Acee

OSPF mailing list

[email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 20 Jan 2011 10:13:01 +0530

Hi Srini,

Actually I am not sure if we dont want them to form an adjacency. I am paranoid about any solution that requires a flag day approach, where one day all routers get upgraded to support a new feature/extension. Given this, i can envisage a scenario when we will have a mix of these routers, with some boxes using AT and some that cant. I believe a CLI knob interop-non-AT-capable-router to control the behavior should be sufficient. The default, when its off, could be to reject any packet that does not carry the AT, if the new auth scheme is turned on. For backward compatibility, you could turn on that knob, that will do as suggested in the original text.

Please note that the AT bit has to be turned on if you want any router to inspect the AT as it will otherwise be unable to parse the incoming packet.

Cheers, Manav

Sent: Thursday, January 20, 2011 9.42 AM

Hi Manav,

While it is expected that routers that support AT and that do not support AT should not form adjacencies, that does not preclude the possibility that they may physically share the same network. The other routers may also running other protocols. My thought was just to ensure that these non-AT supporting routers are not affected/confused by the new extension.

Regards,
Srini.

Hi Srini,

Cheers, Manav

Regards,
Srini.

Hi Manav,

Hi Acee,

Cheers, Manav

Thanks,
Acee

Dear All,
AT Bit Definition:

---

From: Rajesh Shetty <[email-masked]>
Date: Thu, 20 Jan 2011 10:27:41 +0530

Dear Manav,

I agree with all the points mentioned by you in the below mail.
Only problem if we put AT before LLS is, there might exist a router in the
network who supports LLS but not AT (less probability). He will not be able
to decode LLS correctly when packet arrives with AT and LLS. Compatibility
need to support for AT as well as LLS this seems to be a issue.

Thanks
Rajesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bhatia, Manav (Manav)
Sent: Thursday, January 20, 2011 5:22 AM
To: Michael Barnes; [email-masked]
Cc: Acee Lindem
Subject: Re: [OSPF] AT Bit

Hi Michael,

The design was kept this way since this is how it is done in OSPFv2. Besides
getting rid of IPsec the idea is also to bring OSPFv3 at par with OSPFv2 and
we would like both the protocols to behave in a similar fashion. In v2, the
Auth data precedes the LLS block and there is a separate TLV that carries
authentication data for the LLS block. I think we should do the same for the
sake of consistency between the two protocols.

The other idea behind putting AT before LLS was that if we did it the other
way round, then implementations would NOT be able to support AT till they
had at least minimal code that could understand and parse the LLS block. We
didn't want that to happen as chances of seeing nodes supporting AT over LLS
are higher.

I think we can include another subsection that defines a Cryptographic
Authentication TLV for LLS that could be used for OSPFv3. Alternately, we
could respin a one page draft that updates rfc 5613, and permits the
existing crypto auth TLV to be used for OSPFv3 as well. I would personally
prefer the latter approach as its cleaner to keep these things separate.

I don't think we should include the Session ID and Nonce here. That work
will be done in KARP and it will take a looooooooong time before we finalize
on a scheme that fixes OSPF authentication when using manual keying.
Secondly, this draft is about bringing OSPFv3 auth at par with OSPFv2, since
operators are using auth with v2 and are NOT doing it with v3. Implementing
the AT draft is a matter of a few days, however, if you bring in the Session
and the Nonce thing here, then we have already pushed it to a few years. I
don't think we should wait for that long.

Cheers, Manav

---

From: Michael Barnes <[email-masked]>
Date: Wed, 19 Jan 2011 21:22:36 -0800

Hi Manav,

This is a good point. Any router which fully supports RFC5838 should be 
using LLS (see section 2.7), so will be devices in the field using LLS 
before any support AT.

Regards,
Michael

---

From: Acee Lindem <[email-masked]>
Date: Thu, 20 Jan 2011 12:26:22 -0500

Hi Manav, Michael,

> Which means that they would have to add minimal code to support understanding the "L" bit in the Options field and adding the parsing code so that they can reach the start of the AT.

I would not be against mandating support of LLS parsing for OSPFv3 AT support. It is as simple as examining the L-bit and bypassing the LLS block to get to the AT. 

> I suggest that we leave out these details now. If we make a good progress in the karp draft by the time this draft is ready for IESG we could certainly add the required fields as you have suggested…

Agreed.

Thanks,
Acee

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 21 Jan 2011 04:37:16 +0530

Folks,
 
> I would not be against mandating support of LLS parsing for 
> OSPFv3 AT support. It is as simple as examining the L-bit and 
> bypassing the LLS block to get to the AT. 

Then the larger question is that should AT also include the LLS block when computing the hash? 

In either case this needs to be specified in the draft.

> > 
> > I suggest that we leave out these details now. If we make a 
> good progress in the karp draft by the time this draft is 
> ready for IESG we could certainly add the required fields as 
> you have suggested. 
> draft-bhatia-karp-ospf-ip-layer-protection is still an 
> individual submission and I would not like to change things 
> here based on what has been proposed there! 
> 
> Agreed.

Great!

Cheers, Manav

---

From: Michael Barnes <[email-masked]>
Date: Thu, 20 Jan 2011 15:17:24 -0800

> Then the larger question is that should AT also include the LLS block when computing the hash?

I think it should, it is much more straightforward than authenticating 
LLS separately.

> In either case this needs to be specified in the draft.

Most definitely.

Regards,
Michael

---

From: Acee Lindem <[email-masked]>
Date: Thu, 20 Jan 2011 20:09:39 -0500

Hi Manav, Michael, and Srini, 

I think if AT authentication is configured then we must not accept packets without the AT-bit set. For migration, one could migrate one link at a time. For P2P links, both routers would need to support AT. For multi-access links, I think the best way to handle backward compatibility is to recommend a migration plan where different OSPFv3 interface instance IDs are used support groups of OSPFv3 routers that do and do not support AT. Of course, the routers eligible to become DR should support an interface in each group. It is certainly more straight-forward to migrate all the routers on a give link at once. 

Thanks,
Acee