Subject: SRH Mutability and AH

From: Bob Hinden <[email-masked]>
Date: Sat, 13 Apr 2019 09:14:14 -0700

Reading the email thread and looking the new draft <draft-ietf-6man-segment-routing-header-18> as compared the previous version <draft-ietf-6man-segment-routing-header-17>, we would like the working group view on AH and mutability of SRH and its TLVs.

In the context of AH and ICV calculation, there are essentially 3 options:

1) Say nothing at all. Similar to the RFC6554 approach.
   While unstated, an AH ICV implementation would likely have considered it mutable but
   predictable as RH0

  Consequence for the draft:
   - Remove section 7.5 in -18.

2) Whole header content mutable
   Current revision -18. AH ICV zeroes out the full content of the SRH.
   Neither SID list nor TLVs are protected.
   See section 7.5 in -18.

3) Predictable and mutable
   Very close to revision -17.
   TLVs have a flag like HBH/Dest option stating if the option can change en route.
   Both SID list and immutable TLVs are protected by AH.

   Aligned with RFC8200, RH0, RFC4302
   
   Implications for the draft:
   Put back the following text from -17:

------------
Section 2.1 SRH TLVs

 TLVs may change en route at each segment.  To identify when a TLV
 type may change en route the most significant bit of the Type has the
 following significance:

    0: TLV data does not change en route

    1: TLV data does change en route

 Identifying which TLVs change en route, without having to understand
 the Type, is required for Authentication Header Integrity Check Value
 (ICV) computation.  Any TLV that changes en route is considered
 mutable for the purpose of ICV computation, the Type Length and
 Variable Length Data is ignored for the purpose of ICV Computation as
 defined in [RFC4302].

Section 5.4.  AH ICV

 Within the domain, an SR source node which includes SRH and AH
 extension headers can predict the content of the SRH and calculate
 the ICV at the SR source node, ensuring it can be confirmed at the
 destination.
----------------

We have questions about these changes in -18. Given the limited domain applicability of this option, it might be unlikely that AH will ever be used. But even so, there might be value in explicit signaling of which parts of SRH and TLVs are changeable en route and which ones aren’t.

What is the working groups view? Is it important to specify integrity protection for the SID list and TLVs? Or given the controlled domain expectations can it be left without?

Thanks,
Bob & Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 13 Apr 2019 12:22:51 -0400

I think it is important that the draft be clear about what the AH covers 
if it is present.  Admittedly, one way to be clear is to prohibit it.

I also think that the draft (RFC-to-be) needs to be clear about what 
parts of the SRH an SR endpoint is allowed to modify.  i personally 
prefer that as little as possible be modifiable.  But it is more 
important that it be clear than that it be restrcited.

Yours,
Joel

On 4/13/19 12:14 PM, Bob Hinden wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Apr 2019 08:55:27 +1200

Hi Bob,

> In the context of AH and ICV calculation, there are essentially 3 options:

I think there's a 4th option: state explicitly that AH MUST NOT be used
in an SR domain. That there is such a limited domain is clearly
established by https://tools.ietf.org/html/rfc8402#page-6 .

Of your 3 options, I prefer #3, but I think it will need to be
a formal update of RFC4302.

BTW, there's another statement in RFC8402 that may in fact be
imprecise as a result of all this:

>>    Segment Routing extensions that have been
>>    defined in various protocols, leverage the security mechanisms of
>>    these protocols such as encryption, authentication, filtering, etc.

I've never been quite clear what the verb "leverage" means in English,
but it certainly doesn't mean "break" ;-).

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 13 Apr 2019 23:26:12 +0100

Bob Hinden wrote on 13/04/2019 17:14:
> What is the working groups view? Is it important to specify integrity
> protection for the SID list and TLVs? Or given the controlled domain
> expectations can it be left without?
AH deployment is almost non-existent in the wild.  I guess you could 
deploy it for SR headers if you were so inclined, but this would force 
slow-path SR packet processing which seems unlikely for the types of 
network where SR would be deployed.  In other words, this is unlikely to 
be a pressing problem on production networks.

Option #3 is thorough but complex and the mutability determination 
mechanism is specific to this draft.  Complexity is generally unwelcome, 
especially for one-off implementation cases like this.  I can't see 
vendors falling over themselves in the rush to get this code out the door.

Option #2 is of unclear value.

Option #1 is tempting, but it would almost guarantee no implementation 
interoperability if any vendor felt inclined to roll their own.

My preferred option would be Brian's suggestion #4 that AH+SRH be 
prohibited, as the use cases are likely to be limited to procurement 
people churning out tickbox compliance lists.

Nick

---

From: Mark Smith <[email-masked]>
Date: Sun, 14 Apr 2019 08:28:32 +1000

Hi Bob, Ole,

It seems to me that the most robust operations to perform on a packet
in flight are read only.

If processing involves read/write, then it is best that the identity
of the source node of the read/write operation is recorded somehow in
the packet where the read/write operation occurred. Later detected
errors with the read/write operation can be reported via ICMP to the
device that performed them. Manual troubleshooting of a failed
read/write operation would be much easier because there is read/write
operation accountability.

So I think the the least mutability of any of an in flight packet's
field should be the goal, with the ideal being immutability.

So to me, the best way for SR to achieve "TLV mutability" would be for
the node that wishes to perform that mutation to completely replace
the IPv6 and SRH header, with new ones that it originates, including
new or changed TLVs. That new header can include a new AH, calculated
over the new SRH and its contents. This replacement/creation operation
would mean that AH could consider the new SRH and its TLVs completely
immutable. The new IPv6 source address would identify the node that
performed this IPv6/SRH header replacement/creation.

Regards,
Mark.

---

From: Tom Herbert <[email-masked]>
Date: Sun, 14 Apr 2019 12:31:32 -0700

> established by https://tools.ietf.org/html/rfc8402#page-6 .
Brian,

AH is already optional so that users can decided if it's needed in
their use case. I don't see what problem is solved by prohibiting
someone from using an established security mechanism?

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Apr 2019 09:48:01 +1200

> someone from using an established security mechanism?

Well, it's a brutal way of guaranteeing interoperability. A less
brutal approach is an explicit statement that SRH is incompatible
with AH. I don't think there's much difference in practice.

   Brian

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 15 Apr 2019 03:18:06 +0000

Agree with complexity is generally unwelcome. 

SIDs and TLVs should support to be mutable for sure. 

Think about IOAM for SRv6, whatever IOAM TLVs in SRH[1] or Light IOAM using used SIDs[2], we need SIDs and TLVs to be mutable.

Also, if a binding SID maps to insert SID lists in SRH, then the SID list will be modified.

Cheng
[1] https://tools.ietf.org/html/draft-ali-6man-spring-srv6-oam-01
[2] https://tools.ietf.org/html/draft-li-spring-light-weight-srv6-ioam-00

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Nick Hilliard
Sent: Sunday, April 14, 2019 6:26 AM
To: Bob Hinden <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: SRH Mutability and AH

> expectations can it be left without?
AH deployment is almost non-existent in the wild.  I guess you could deploy it for SR headers if you were so inclined, but this would force slow-path SR packet processing which seems unlikely for the types of network where SR would be deployed.  In other words, this is unlikely to be a pressing problem on production networks.

Option #3 is thorough but complex and the mutability determination mechanism is specific to this draft.  Complexity is generally unwelcome, especially for one-off implementation cases like this.  I can't see vendors falling over themselves in the rush to get this code out the door.

Option #1 is tempting, but it would almost guarantee no implementation interoperability if any vendor felt inclined to roll their own.

My preferred option would be Brian's suggestion #4 that AH+SRH be prohibited, as the use cases are likely to be limited to procurement people churning out tickbox compliance lists.

Nick

---

From: Ole Troan <[email-masked]>
Date: Mon, 15 Apr 2019 08:48:16 +0200

Hi Brian,

> established by https://tools.ietf.org/html/rfc8402#page-6 .

Would you be able to propose text / text implications for that option?

Is a “AH is not defined…” an alternative?
To leave the door open for future extensions, or must this be a once and for all decision?

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Mon, 15 Apr 2019 19:04:18 +1000

On Mon., 15 Apr. 2019, 13:18 Chengli (Cheng Li), <[email-masked]>
wrote:

> Think about IOAM for SRv6, whatever IOAM TLVs in SRH[1] or Light IOAM
> using used SIDs[2], we need SIDs and TLVs to be mutable.
>

If this occurs, the Source Address in the packet should also be set to all
zeros, meaning unspecified, as the previous SA would now be inaccurate and
incorrect.

> network where SR would be deployed.  In other words, this is unlikely to be
> a pressing problem on production networks.
>
> especially for one-off implementation cases like this.  I can't see vendors
> falling over themselves in the rush to get this code out the door.
>
> prohibited, as the use cases are likely to be limited to procurement people
> churning out tickbox compliance lists.
>
> Nick
>

---

From: Xiejingrong <[email-masked]>
Date: Mon, 15 Apr 2019 11:26:22 +0000

Hi,
I agree with Brain:
(1) the 4th option, to prohibit the SRH+AH currently, is my preferred option. 
(2) there have been new IPv6 extensions proposed ever since RFC4302, e.g., RFC6275 and SRH, and RFC4302 seems unsuitable to these changes/proposals.

RFC4302:
   The section 3.1.1 said, The destination options extension header(s) could appear before or after or both before and after the AH header depending on the semantics desired. 
   And then in the following diagram, it describes that the AH is required to be put between the Routing-header and Destination-Option-header if they exist in this order (RH--DOH). 
   This is the normal order of IPv6 extension headers, but:

RFC6275:
   And in RFC6275 - Mobility Support in IPv6, the section 6.3 said: 
   The Home Address option MUST be placed as follows: //Background: The Home Address option is carried by the Destination Option extension header.
   o  After the routing header, if that header is present
   o  Before the Fragment Header, if that header is present
   o  Before the AH Header or ESP Header, if either one of those headers is present
   This implies that, if RH--DOH(with Home Address Option) both be present in the RH--DOH order, then adding AH support will result the format of 'RH--DOH(with Home Address Option)--AH'. See, the AH is *after* (the RH and the following DOH) !

RFC4302 seems unsuitable to new IPv6 extensions and requirements in some part, especially for the data-plane AH like RFC6275 or this SRH draft, or a BIERv6 draft I was thinking of:
The BIERv6 encapsulation (https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-00), for example, may have to require the same as RFC6275, to force the AH after the RH--DOH if it support AH.

So my suggestion is to prohibit the SRH+AH currently, as the 4th option Brian suggested.
And Let the AH support as a further work, considering the raising cases and requirements, and making necessary change to RFC4302.

Thanks
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Sunday, April 14, 2019 4:55 AM
To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: SRH Mutability and AH

Hi Bob,

> In the context of AH and ICV calculation, there are essentially 3 options:

I think there's a 4th option: state explicitly that AH MUST NOT be used in an SR domain. That there is such a limited domain is clearly established by https://tools.ietf.org/html/rfc8402#page-6 .

Of your 3 options, I prefer #3, but I think it will need to be a formal update of RFC4302.

>>    these protocols such as encryption, authentication, filtering, etc.

I've never been quite clear what the verb "leverage" means in English, but it certainly doesn't mean "break" ;-).

   Brian

---

From: Tom Herbert <[email-masked]>
Date: Mon, 15 Apr 2019 07:47:53 -0700

>    This implies that, if RH--DOH(with Home Address Option) both be present in the RH--DOH order, then adding AH support will result the format of 'RH--DOH(with Home Address Option)--AH'. See, the A…
Hi Jingrong,

RFC6275 clearly allows use of AH/IPsec with HAO and has a full
discussion on the topic in section 11.3.2. It describes the provisions
for a sender/receiver to correctly perform AH ICV with the HAO present
and this has been implemented for a long time. I'm not seeing how it's
broken, nor why segment routing with AH is necessarily broken. It's
seems to me to just be a matter of specifying the interaction between
AH and SR-- basically, the SRH draft should have an equivalent section
to 11.3.2 in RFC6275.

But, before it's possible to describe the interaction with AH, we need
requirements as to _what_ header data can change in flight and _how_
it can change in flight. These have not been articulated for SR, and
to me this really is the fundamental question. This is relevant for
more than just figuring out how to make AH work, there are security
and operational implications when intermediate devices are allowed to
modify packets. Even in the current SRH draft there might be
unanswered implications. For instance, the HMAC option includes the
segment list in the input text, so if one hop modifies the segment
list and a later hop attempts to validate the HMAC, it seems like
verification would fail in a similar way that AH verification would
fail if the segment list were covered.

Thanks,
Tom

---

From: Mark Smith <[email-masked]>
Date: Tue, 16 Apr 2019 09:58:22 +1000

On Tue, 16 Apr 2019 at 00:48, Tom Herbert <[email-masked]> wrote:
<snip>
> to me this really is the fundamental question.

+1

This is relevant for
> modify packets.

A critical factor in operating a production network is to maximise
service availability (I think it is the most critical factor of 4
Network Critical Success Factors*). As faults and failures are
inevitable, minimising how long it takes to identify what the fault is
and where it has occurred is then also critical, in particular for
commercial networks with paying customers and potentially service
level agreements that compensate customers for unplanned downtime.

It is common for the fault identification step to take far long than
fault rectification. I think attribution of which device performed
what operation on a packet, and obviousness in operation (the
principle of least surprise) can greatly help reduce the fault
determination and identification time.

Regards,
Mark.

* Network Critical Success Factors (NCSFs) section -
https://blog.apnic.net/2016/10/25/trouble-nat-part-1/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Apr 2019 13:52:41 +1200

> To leave the door open for future extensions, or must this be a once and for all decision?

Yes, having read subsequent discussion I think "this will not work"
is probably better than a "MUST NOT". In the absence of protocol police,
"this will not work" is in fact a stronger warning.

It's up to the authors of course, but something like:

Since this document defines mutable fields that were not foreseen
when the IP Authentication Header [RFC4302] was defined, current
implementations of RFC4302 are incompatible with the Segment Routing
Extension Header and will not work correctly in an IPv6 Segment Routing
domain [RFC8402].

Then leave the ICV question aside for future work. 

Otherwise I don't see how to avoid an Updates: 4302 and all the
work that implies.

Regards
    Brian

---

From: Xiejingrong <[email-masked]>
Date: Tue, 16 Apr 2019 11:44:05 +0000

Hi Tom,

I'm not seeing how it's broken, nor why segment routing with AH is necessarily broken. It's seems to me to just be a matter of specifying the interaction between AH and SR-- basically, the SRH draft should have an equivalent section to 11.3.2 in RFC6275.

Right in this 11.3.2 of rfc6275 (also there is some similar text in 6.3):
      The Destination Options header in which the Home Address destination
      option is inserted MUST appear in the packet after the routing
      header, if present, and before the IPsec (AH [4] or ESP [5])
      header, so that the Home Address destination option is processed
      by the destination node before the IPsec header is processed.
This's the where I think the AH was broken: if DestOptHdr is located after RoutingHeader, the DestOptHdr is assumed to be the last EH (which is *after* the AH, see 4.1 of rfc8200 or 3.1.1 of rfc6275), but this RFC requires DAO located *before* the AH.

Thanks
Jingrong

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Monday, April 15, 2019 10:48 PM
To: Xiejingrong <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: SRH Mutability and AH

Hi Jingrong,

RFC6275 clearly allows use of AH/IPsec with HAO and has a full discussion on the topic in section 11.3.2. It describes the provisions for a sender/receiver to correctly perform AH ICV with the HAO present and this has been implemented for a long time. I'm not seeing how it's broken, nor why segment routing with AH is necessarily broken. It's seems to me to just be a matter of specifying the interaction between AH and SR-- basically, the SRH draft should have an equivalent section to 11.3.2 in RFC6275.

But, before it's possible to describe the interaction with AH, we need requirements as to _what_ header data can change in flight and _how_ it can change in flight. These have not been articulated for SR, and to me this really is the fundamental question. This is relevant for more than just figuring out how to make AH work, there are security and operational implications when intermediate devices are allowed to modify packets. Even in the current SRH draft there might be unanswered implications. For instance, the HMAC option includes the segment list in the input text, so if one hop modifies the segment list and a later hop attempts to validate the HMAC, it seems like verification would fail in a similar way that AH verification would fail if the segment list were covered.

Thanks,
Tom

---

From: Xiejingrong <[email-masked]>
Date: Tue, 16 Apr 2019 11:51:11 +0000

see 4.1 of rfc8200 or 3.1.1 of <rfc4302>, not 3.1.1 of rfc6275.

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Xiejingrong
Sent: Tuesday, April 16, 2019 7:44 PM
To: Tom Herbert <[email-masked]>
Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: RE: SRH Mutability and AH

Hi Tom,

Thanks
Jingrong

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]]
Sent: Monday, April 15, 2019 10:48 PM
To: Xiejingrong <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: SRH Mutability and AH

Hi Jingrong,

Thanks,
Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Apr 2019 08:33:37 +1200

Hi,

> I'm not seeing how it's broken, nor why segment routing with AH is necessarily broken. 

What is very confusing to me is this statement in the draft:

"7.5.  AH ICV computation

   For the purpose of AH ICV calculation the SRH is considered mutable,..."

If that statement is necessary, there must be a problem with
existing implementations of AH. Also if that statement is necessary,
this draft should update RFC4302.

Nit: Neither "AH" nor "ICV" is defined in the draft, and there is
no citation of RFC4302.

As I already suggested, simply stating that SRH6 is incompatibale
with RFC4302 might be more straightforward.

If the quoted statement is unnecessary, why is it even there?

Regards
   Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 17 Apr 2019 11:12:33 +1000

> with RFC4302 might be more straightforward.

This seems a bit to me like avoiding this issue by putting it in the too
hard basket.

I think it would set a precedent of "if it seems hard to make a new
mechanism compatible with an existing mechanism, prohibit the use of the
inconvenient mechanism". We could end up with a lot of exception contexts
and prohibitions that operators have to try to remember, either during
network construction or troubleshooting (and those exception cases are down
the list of fault causes, behind common cases, so they take time to get to,
delaying fixing the fault.)

If a packet was dropped somewhere in the network because it mistakenly
contained a prohibited AH (or some other prohibited EH in different
context), how would the operator know that was the problem?

This discussion around AH is also seems odd in the context of the HMAC TLV,
who's purpose is:.

   The HMAC TLV is used to verify the source of a packet is permitted to
   use the current segment in the destination address of the packet, and
   ensure the segment list is not modified in transit.

Why is there discussion to specifically loosen AH so that it doesn't detect
a segment list being changed in transit, to then invent a SR specific TLV
that does?

Could AH be used instead of this SR specific TLV? If not, I think it should
be explained why not.

> > I'm not seeing how it's broken, nor why segment routing with AH is
> necessarily broken. It's seems to me to just be a matter of specifying the
> interaction between AH and SR-- basically, the SRH draft should have an
> equivalent section to 11.3.2 in RFC6275.
> >
> > This's the where I think the AH was broken: if DestOptHdr is located
> after RoutingHeader, the DestOptHdr is assumed to be the last EH (which is
> *after* the AH, see 4.1 of rfc8200 or 3.1.1 of rfc6275), but this RFC
> requires DAO located *before* the AH.
> >
> > Thanks
> > Jingrong
> >
> > Cc: Brian E Carpenter <[email-masked]>; Bob Hinden <
> [email-masked]>; IPv6 List <[email-masked]>
> >> (2) there have been new IPv6 extensions proposed ever since RFC4302,
> e.g., RFC6275 and SRH, and RFC4302 seems unsuitable to these
> changes/proposals.
> >>
> >> RFC4302:
> >>    The section 3.1.1 said, The destination options extension header(s)
> could appear before or after or both before and after the AH header
> depending on the semantics desired.
> >>    And then in the following diagram, it describes that the AH is
> required to be put between the Routing-header and Destination-Option-header
> if they exist in this order (RH--DOH).
> >>    The Home Address option MUST be placed as follows: //Background: The
> Home Address option is carried by the Destination Option extension header.
> >>    This implies that, if RH--DOH(with Home Address Option) both be
> present in the RH--DOH order, then adding AH support will result the format
> of 'RH--DOH(with Home Address Option)--AH'. See, the AH is *after* (the RH
> and the following DOH) !
> >>
> > Hi Jingrong,
> >
> discussion on the topic in section 11.3.2. It describes the provisions for
> a sender/receiver to correctly perform AH ICV with the HAO present and this
> has been implemented for a long time. I'm not seeing how it's broken, nor
> why segment routing with AH is necessarily broken. It's seems to me to just
> be a matter of specifying the interaction between AH and SR-- basically,
> the SRH draft should have an equivalent section to 11.3.2 in RFC6275.
> >
> requirements as to _what_ header data can change in flight and _how_ it can
> change in flight. These have not been articulated for SR, and to me this
> really is the fundamental question. This is relevant for more than just
> figuring out how to make AH work, there are security and operational
> implications when intermediate devices are allowed to modify packets. Even
> in the current SRH draft there might be unanswered implications. For
> instance, the HMAC option includes the segment list in the input text, so
> if one hop modifies the segment list and a later hop attempts to validate
> the HMAC, it seems like verification would fail in a similar way that AH
> verification would fail if the segment list were covered.
> >
> > Thanks,
> > Tom
> >
> >> RFC4302 seems unsuitable to new IPv6 extensions and requirements in
> some part, especially for the data-plane AH like RFC6275 or this SRH draft,
> or a BIERv6 draft I was thinking of:
> >> The BIERv6 encapsulation (
> https://tools.ietf.org/html/draft-xie-bier-ipv6-encapsulation-00), for
> example, may have to require the same as RFC6275, to force the AH after the
> RH--DOH if it support AH.
> >>
> >> And Let the AH support as a further work, considering the raising cases
> and requirements, and making necessary change to RFC4302.
> >>
> >> Thanks
> >> Jingrong
> >>
> >>> Reading the email thread and looking the new draft
> <draft-ietf-6man-segment-routing-header-18> as compared the previous
> version <draft-ietf-6man-segment-routing-header-17>, we would like the
> working group view on AH and mutability of SRH and its TLVs.
> >>>
> in an SR domain. That there is such a limited domain is clearly established
> by https://tools.ietf.org/html/rfc8402#page-6 .
> >>

---

From: Xiejingrong <[email-masked]>
Date: Wed, 17 Apr 2019 02:05:40 +0000

Hi Mark,
"if it seems hard to make a new mechanism compatible with an existing mechanism, prohibit the use of the inconvenient mechanism"
The preceding IPv6 Destination Address(DA) is a special address (SRv6 SID) allowing what the right format a packet could be.
One use this special address, then one should know how to shape the packet right -- not use AH with SRH in my opinion to this discussion.

From: Mark Smith [mailto:[email-masked]]
Sent: Wednesday, April 17, 2019 9:13 AM
To: Brian E Carpenter <[email-masked]>
Cc: Xiejingrong <[email-masked]>; Tom Herbert <[email-masked]>; IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: SRH Mutability and AH

On Wed., 17 Apr. 2019, 06:21 Brian E Carpenter, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

"7.5.  AH ICV computation

This seems a bit to me like avoiding this issue by putting it in the too hard basket.

I think it would set a precedent of "if it seems hard to make a new mechanism compatible with an existing mechanism, prohibit the use of the inconvenient mechanism". We could end up with a lot of exception contexts and prohibitions that operators have to try to remember, either during network construction or troubleshooting (and those exception cases are down the list of fault causes, behind common cases, so they take time to get to, delaying fixing the fault.)

If a packet was dropped somewhere in the network because it mistakenly contained a prohibited AH (or some other prohibited EH in different context), how would the operator know that was the problem?

This discussion around AH is also seems odd in the context of the HMAC TLV, who's purpose is:.

Why is there discussion to specifically loosen AH so that it doesn't detect a segment list being changed in transit, to then invent a SR specific TLV that does?

Could AH be used instead of this SR specific TLV? If not, I think it should be explained why not.

Regards
   Brian

On 16-Apr-19 23:51, Xiejingrong wrote:
> From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Xiejingrong
> To: Tom Herbert <[email-masked]<mailto:[email-masked]>>
> Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>; Bob Hinden <[email-masked]<mailto:[email-masked]>>
> From: Tom Herbert [mailto:[email-masked]<mailto:[email-masked]>]
> To: Xiejingrong <[email-masked]<mailto:[email-masked]>>
> Cc: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>; Bob Hinden <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>
> On Mon, Apr 15, 2019 at 4:27 AM Xiejingrong <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi,
>> I agree with Brain:
>> From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E
>> Carpenter
>> To: Bob Hinden <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 17 Apr 2019 10:45:21 +0100

> This seems a bit to me like avoiding this issue by putting it in the too 

Mark, this is the nub of the problem.  RFC4302 kicked that can down the 
road in section 3.3.3.1 by stating that it was not going to standardise 
any framework for handling mutable fields in the context of AH, and that 
each future protocol would have to invent some protocol-specific way of 
handling it.  The context for making this decision, btw, is entirely 
understandable.

So it's not draft-ietf-6man-segment-routing-header that's avoiding the 
issue.  That precedent was set 15 years ago.

Nick

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 17 Apr 2019 13:36:48 +0000

Hi all, below is some background on the text in 18, and a proposed option along the lines of Brian’s/Nick's suggestion.

It’s useful to recall that the SR Domain is a trusted domain, as defined in RFC8402 Section 2 and Section 8.2. The SR Source is trusted to add an SRH (optionally verified via the HMAC TLV in this draft), and segments advertised within the domain are trusted to be accurate and advertised by trusted sources via a secure control plane.  The SR domain does not rely on AH to secure the SRH.

As such, revision 18 defined a simple solution for AH processing of SRH:
 - When calculating AH ICV, replace the SRH with 0’s.

However there is another valid option, as Brian has described, which could be better: 
 - SRH with AH is not defined in the SR Domain.  

Brian used incompatible but I think not defined may be more clear.

<NEW>
7.5 SRH with AH
The SR Domain is a trusted domain, as defined in RFC8402 Section 2 and Section 8.2. The SR Source is trusted to add an SRH (optionally verified via the HMAC TLV in this document), and segments advertised within the domain are trusted to be accurate and advertised by trusted sources via a secure control plane.  As such the SR Domain does not rely on AH to secure the SRH.

The use of SRH with AH by an SR Source node is not defined in this document. Future documents may define use of SRH with AH and its processing.

</NEW>

Darren

> On Apr 13, 2019, at 12:14 PM, Bob Hinden <[email-masked]> wrote:
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 17 Apr 2019 14:27:50 +0000

Darren,

This text looks good. But you might want to add one sentence that says what an SRv6 egress node should do when it receives a packet that includes both SRH and AH. Options are:

- drop the packet
- ignore the AH
- zero out the SRH for the purposes of authentication
- ignore the SRH for the purposes of authentication

Clearly, some of these options are much better than others.

                                                        Ron

                                                                                    Ron

> <NEW>
> 7.5 SRH with AH
> The SR Domain is a trusted domain, as defined in RFC8402 Section 2 and
> Section 8.2. The SR Source is trusted to add an SRH (optionally verified via the
> HMAC TLV in this document), and segments advertised within the domain are
> trusted to be accurate and advertised by trusted sources via a secure control
> plane.  As such the SR Domain does not rely on AH to secure the SRH.
> 
> The use of SRH with AH by an SR Source node is not defined in this document.
> Future documents may define use of SRH with AH and its processing.
> 
> </NEW>
--------------------------------------------------------------

Juniper Internal

---

From: Tom Herbert <[email-masked]>
Date: Wed, 17 Apr 2019 07:41:27 -0700

> any framework for handling mutable fields in the context of AH, and that

Nic,

It is not clear which fields in the SRH are being specified as
mutable. Until there is clarity in that, I think it is hard to
determine how AH and HMAC TLV need to deal with the mutable fields.
Zero'ing out the SRH "for the purpose" of AH would seem to imply
pretty much the whole header is mutable, but then the HMAC TLV
specifies that the segment list is included in the input text so that
would imply that the segment list is not mutable. Zero'ing out the
TLVs for AH makes them mutable, but prior to version -18 of the draft
the TLV included a change bit similar to that used for HBH and
Destination Options in RFC8200 which implied only the option data is
mutable.

IMO, all this would much clearer if there was simply a statement in
normative language as to what header data may be changed in flight.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Apr 2019 11:37:26 +1200

> Brian used incompatible but I think not defined may be more clear.

Works for me

Regards
   Brian

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 23 Apr 2019 17:25:42 +0000

Hi Ron, the consistent approach would be to say the use of SRH with AH by an SR source node and processing at an SR segment endpoint node is not defined in this document.

Darren

> On Apr 17, 2019, at 10:27 AM, Ron Bonica <[email-masked]> wrote:
> 
> Darren,
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 24 Apr 2019 02:41:15 +0000

Darren,

That's fine, provided you all a sentence like the one below:

"Until processing rules are defined, the following behaviors are all acceptable:

- behavior A 
- behavior B 
- behavior C"

                                                  Ron

Juniper Internal

> From: Darren Dukes (ddukes) <[email-masked]>
> Sent: Tuesday, April 23, 2019 10:26 AM
> To: Ron Bonica <[email-masked]>
> Hi Ron, the consistent approach would be to say the use of SRH with AH by an
> SR source node and processing at an SR segment endpoint node is not defined
> in this document.
> 
> Darren
> 
> 
> > This text looks good. But you might want to add one sentence that says what
> an SRv6 egress node should do when it receives a packet that includes both
> SRH and AH. Options are:
> >
> > - drop the packet
> > - ignore the AH
> >> The SR Domain is a trusted domain, as defined in RFC8402 Section 2
> >> and Section 8.2. The SR Source is trusted to add an SRH (optionally
> >> verified via the HMAC TLV in this document), and segments advertised
> >> within the domain are trusted to be accurate and advertised by
> >> trusted sources via a secure control plane.  As such the SR Domain does not
> rely on AH to secure the SRH.
> >>

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Apr 2019 09:07:31 +0200

Ron,

> "Until processing rules are defined, the following behaviors are all acceptable:

Iff we are fine with undefined behaviour, then the document shouldn't have to turn around and define it in the next sentence.

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Wed, 24 Apr 2019 08:00:24 -0400

On Wed, Apr 24, 2019, 3:07 AM Ole Troan <[email-masked]> wrote:

> Iff we are fine with undefined behaviour, then the document shouldn't have
> to turn around and define it in the next sentence.
>

Ole,

I don't see how this can be undefined in a proposed standard. If we say
it's AH is undefined then what would it mean when someone receives a packet
with both AH and SRH? The receiver has to do _something_ with the packet.
The protocol specification should specify the correct and interoperable
behavior.

Tom

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Apr 2019 14:13:35 +0200

Hi Tom,

> I don't see how this can be undefined in a proposed standard. If we say it's AH is undefined then what would it mean when someone receives a packet with both AH and SRH? The receiver has to do _something_ with the packet. The protocol specification should specify the correct and interoperable behavior.

https://en.wikipedia.org/wiki/Undefined_behavior

Anything the implementation does with the packet is "fine". That's what undefined would imply.

Now, I don't think that was exactly what was proposed. I think it was "not defined by this specification".

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Wed, 24 Apr 2019 08:39:47 -0400

On Wed, Apr 24, 2019, 8:13 AM Ole Troan <[email-masked]> wrote:

> > Iff we are fine with undefined behaviour, then the document shouldn't
> have to turn around and define it in the next sentence.
> >
> > Ole,
> >

Ole,

Then the question is: why isn't the behavior being defined here? Other
specifications of extension headers specify the interaction with AH.

HMAC TLV indicates the segment list is not mutable; segments left and final
destination are mutable but predictable so defining AH coverage of segment
list portion is straightforward. TLV type can include a change bit like HBH
and DO, as in previous draft versions, that allows Option Data to be
mutable and zeroed for AH. This would be consistent with RFC8200 and
RFC4302.

Tom

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Apr 2019 14:49:34 +0200

Tom,

> Then the question is: why isn't the behavior being defined here? Other specifications of extension headers specify the interaction with AH.

I assumed this was the exploration of the 4th option:

"4th option: state explicitly that AH MUST NOT be used
in an SR domain".

In which case there is no interaction with AH.

> HMAC TLV indicates the segment list is not mutable; segments left and final destination are mutable but predictable so defining AH coverage of segment list portion is straightforward. TLV type can include a change bit like HBH and DO, as in previous draft versions, that allows Option Data to be mutable and zeroed for AH. This would be consistent with RFC8200 and RFC4302.

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Wed, 24 Apr 2019 09:33:58 -0400

Ole,

Option #3 would properly define the interaction between AH and SRH. Is that
still considered a valid option?

Tom

> > HMAC TLV indicates the segment list is not mutable; segments left and
> final destination are mutable but predictable so defining AH coverage of
> segment list portion is straightforward. TLV type can include a change bit
> like HBH and DO, as in previous draft versions, that allows Option Data to
> be mutable and zeroed for AH. This would be consistent with RFC8200 and
> RFC4302.
>
> Cheers,
> Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 24 Apr 2019 15:38:06 +0200

Tom,

> Option #3 would properly define the interaction between AH and SRH. Is that still considered a valid option?

Yes, this thread is here to try to find consensus among one of the 4 options.

Cheers,
Ole

---

From: Ron Bonica <[email-masked]>
Date: Wed, 24 Apr 2019 19:55:17 +0000

Ole,

Darren's text can be interpreted in any of the following ways:

- When an implementation receives a packet that includes both the SRH and the AH, it MUST discard the packet
- When an implementation receives a packet that includes both the SRH and the AH, it MAY discard the packet. However, if it doesn't discard the packet, it MUST ignore the AH.
- When an implementation receives a packet that includes both the SRH and the AH, it MUST NOT discard the packet and it MUST ignore the AH.

Which is it? If we know which, why not articulate it?

                                                Ron

Juniper Internal

> From: Ole Troan <[email-masked]>
> Sent: Wednesday, April 24, 2019 12:08 AM
> Cc: Darren Dukes (ddukes) <[email-masked]>; 6man WG <[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Apr 2019 08:23:01 +1200

> Which is it? If we know which, why not articulate it?

Why does it matter? If the behaviour is undefined, any operator that
chooses to run both AH and SRV6 is, well, foolish. MUST NOT is just the
strongest way of saying that.

My test is "if I was coding this, what would I put in my code?"
In this case, the answer is "nothing". I'd put "don't do this"
in the documentation.

   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Apr 2019 16:51:46 -0400

If SRH were always used in conjunction with an encapsulating header, 
then saying "do not use AH with that header" would seem defensible.  I 
might be tempted to add "doing so increases the chance of discard of the 
packet instead of processing", but that is a judgment call.

However, the current specification still calls for hosts to use SRH with 
their base IPv6 header.  Implementing a rule to not use AH which SRH 
packets introcues:
1) prohibition on using AH in many cases where it ought to be usable
2) Code complexity to make sure that the two code paths do not both get 
invoked, since they are controlled by separate policies.

Yours,
Joel

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 24 Apr 2019 20:58:08 +0000

Hi Ron.

This document does not define how an SR Source node, nor SR Segment Endpoint node, processes AH with SRH preceding it. It leaves that to another document.
As such it should not prescribe processing requirements, i.e. stating any of the things below has no impact on interoperability since the SR Source processing of AH with SRH is not defined either.

Darren

> On Apr 24, 2019, at 3:55 PM, Ron Bonica <[email-masked]> wrote:
> 
> Ole,
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 24 Apr 2019 17:56:14 -0400

On Wed, Apr 24, 2019, 4:23 PM Brian E Carpenter <[email-masked]>
wrote:

> > - When an implementation receives a packet that includes both the SRH
> and the AH, it MAY discard the packet. However, if it doesn't discard the
> packet, it MUST ignore the AH.
> > - When an implementation receives a packet that includes both the SRH
> and the AH, it MUST NOT discard the packet and it MUST ignore the AH.
> >

Maybe,  but then an attacker would be quite wise to send a packet with AH
and SR if the behavior is undefined and unpredictable.

Be liberal in what you receive is applicable here. A host stack needs to do
something when it receives these packets...

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 24 Apr 2019 23:46:21 +0100

> Which is it? If we know which, why not articulate it?

Can we clarify what we're discussing here because I'm confused.

1. AH configured on routers in an SRv6 domain where the operator wants 
to implement header authentication on their SRv6 underlay.

2. generic hosts sending AH-authenticated packets which happen to pass 
through a SRv6 domain.

3. generic hosts sending AH-authenticated packets which terminate in a 
SRv6 transit domain (i.e. where the payload not encapsulated inside the 
ipv6 packet), or the other way around.

4. a bit of everything.

5. something else entirely?

Scenario #1 is going to be exotic.  I wouldn't lose sleep if the RFC 
stated that AH is defined not to work in this situation.

Scenario #2 will not be affected because the SRH will be inserted into 
the packet on ingress to the SRv6 domain and removed on egress. The net 
effect will be that the original packet headers should be intact.

Scenario #3 is a bit messy but could be dealt with by insisting that the 
ICV should be computed after removing the SRH.

Nick

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Apr 2019 18:53:10 -0400

As I understand it, there is one more case.  A host inside the domain 
sending a packet with SRH to another host inside the domain.  one would 
normally expect such a host to be able to use or not use AH as it 
chooses.  By the proposed text, the host is prohibited from using AH.

Yours,
Joel

On 4/24/19 6:46 PM, Nick Hilliard wrote:
>> and the AH, it MUST discard the packet
>> and the AH, it MAY discard the packet. However, if it doesn't discard 
>> the packet, it MUST ignore the AH.

---

From: Ron Bonica <[email-masked]>
Date: Wed, 24 Apr 2019 23:47:45 +0000

Darren,

I suppose that this is acceptable so long as discarding the packet is an acceptable behavior until the correct behavior is defined.

                                                     Ron

Juniper Internal

> Sent: Wednesday, April 24, 2019 1:58 PM
> Cc: Ole Troan <[email-masked]>; 6man WG <[email-masked]>
> This document does not define how an SR Source node, nor SR Segment
> Endpoint node, processes AH with SRH preceding it. It leaves that to another
> document.
> As such it should not prescribe processing requirements, i.e. stating any of the
> things below has no impact on interoperability since the SR Source processing
> of AH with SRH is not defined either.
> 
> Darren
> 
> 
> > - When an implementation receives a packet that includes both the SRH and
> the AH, it MAY discard the packet. However, if it doesn't discard the packet, it
> MUST ignore the AH.
> > - When an implementation receives a packet that includes both the SRH and
> the AH, it MUST NOT discard the packet and it MUST ignore the AH.
> >

---

From: Tom Herbert <[email-masked]>
Date: Wed, 24 Apr 2019 18:27:05 -0700

Ron,

That means we need to add new code into the stack probably into the AH
layer just to detect that an SRH header was previously in the packet--
a lot of complexity for an "interim" solution. I am completely missing
why this option is better than just defining the correct behavior in
the first place.

Tom

---

From: Mark Smith <[email-masked]>
Date: Thu, 25 Apr 2019 14:40:40 +1000

On Thu., 25 Apr. 2019, 11:27 Tom Herbert, <[email-masked]> wrote:

> > I suppose that this is acceptable so long as discarding the packet is an
> acceptable behavior until the correct behavior is defined.
>
> Ron,
>

I think a related question is what ICMP error message should be generated
in this case, to help the operater know that a protocol prohibited AH
header was received?

I also think this starting to go down the path of defining different
"dialects" of IPv6 for different use contexts. It's always better to have a
single dialect, however if there are going to be multiple dialects, then
they should be being given names or more likely subversion/version numbers,
similar to how we name dialects of spoken and written languages.

Regards,
Mark.

> > > >>> "Until processing rules are defined, the following behaviors are
> all
> > > >> acceptable:
> > > >>>
> > > >>> - behavior A
> > > >>> - behavior B
> > > >>> - behavior C"
> > > >>

---

From: Ole Troan <[email-masked]>
Date: Thu, 25 Apr 2019 09:40:24 +0200

Hi Mark,

> I think a related question is what ICMP error message should be generated in this case, to help the operater know that a protocol prohibited AH header was received?
> 
> 
> I also think this starting to go down the path of defining different "dialects" of IPv6 for different use contexts. It's always better to have a single dialect, however if there are going to be multiple dialects, then they should be being given names or more likely subversion/version numbers, similar to how we name dialects of spoken and written languages.

Can you state which of the 4 options you prefer. Or if none, provide text?

Cheers,
Ole

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 25 Apr 2019 13:53:19 +0000

Hi Tom, there is no interoperability necessary for processing that is not defined, so in my implementations I would not change AH from whatever it’s doing today.

Darren

On Apr 24, 2019, at 9:27 PM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Apr 24, 2019 at 4:48 PM Ron Bonica
<rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Darren,

Ron,

Tom

                                                    Ron

Juniper Internal

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 24, 2019 1:58 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Ole Troan <[email-masked]<mailto:[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: SRH Mutability and AH

Hi Ron.

Darren

On Apr 24, 2019, at 3:55 PM, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Ole,

                                              Ron

Juniper Internal

-----Original Message-----
From: Ole Troan <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 24, 2019 12:08 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; 6man WG
<[email-masked]<mailto:[email-masked]>>
Subject: Re: SRH Mutability and AH

Ron,

"Until processing rules are defined, the following behaviors are all
acceptable:

- behavior A
- behavior B
- behavior C"

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 Apr 2019 08:07:45 -0700

On Thu, Apr 25, 2019, 9:53 AM Darren Dukes (ddukes) <[email-masked]>
wrote:

> Hi Tom, there is no interoperability necessary for processing that is not
> defined, so in my implementations I would not change AH from whatever it’s
> doing today.
>

Darren,

It's not just interoperability, it's also robustness and security. There is
no way we can knowingly allow protocols with non-deterministic behavior in
a widely deployed implementation. Implementations need guidance. If IETF
does not provide that guidance, then implementations will make up their own
rules which is how we end up with de facto standards.

Currently, upstream Linux will treat SRH as routing type 0 for AH ICV. This
won't work since there is additional header in SRH and it does not account
for TLVs. It is highly unlikely that the interim solution of disallowing
SRH+AH would be accepted into Linux unless there is a clear argument that
is broken. So Linux needs to be fixed. Unless we get further guidance, I
will post a fix that assumes the segment list is unmutable (like HMAC TLV)
and assumes that TLV types contain a change bit and are processed just like
DO and HBH options are (i.e. only Option Data can be mutable, SR TLVs types
and length are immutable, and TLVs can neither be added nor deleted). Is
this acceptable?

Tom

>
> Darren
>
>
> On Apr 24, 2019, at 9:27 PM, Tom Herbert <[email-masked]> wrote:
>
> Cc: Darren Dukes (ddukes) <[email-masked]>; 6man WG
>
> <[email-masked]>
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 26 Apr 2019 13:49:38 +0000

Hi Tom, as stated previously the SR Domain does not rely on AH to secure the SRH.  Thus this document should not define how AH processes SRH in the SR Domain.

As you know an implementation has to do a lot more than follow RFCs to be robust and secure.
Engineers have have to write secure and robust code to make secure and robust implementations.

For example, I see Linux net/ipv6/ah6.c:ipv6_rearrange_rthdr makes the invalid assumption that all routing header types use the same type 0 format.
This is certainly not what RFC2460, nor RFC8200, nor RFC4302 say to do.
In fact someone even took the effort to explicitly state the assumption in a comment "For the same reason we can assume that this option is of type 0.”
This is not secure, nor robust coding.  Especially in security software!

Let's start by fixing the bad code in Linux before we start writing more code for AH processing that is not defined.

In this case you should call net_dbg_ratelimted and return -EINVAL for any routing header type other than type 2 (the only routing header type with AH processing defined in an RFC that is not deprecated).
Then rewrite ipv6_rearrange_rthdr for type 2 routing header, as per RFC6275, and stop calling ipv6_rearrange_rthdr during ah6_input processing which is clearly not secure.

Now that the bug in Linux AH processing is fixed, and you’ve made no assumptions about AH processing of extension header types that are not defined, you don’t need to make any further changes to AH processing.

Given that secure and robust coding is standard practice in security software implementations (one would hope), I think it’s entirely appropriate that we leave the text to state AH processing of SRH is not defined and we can all stop spending our time on this thread.

Darren

On Apr 25, 2019, at 11:07 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Apr 25, 2019, 9:53 AM Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom, there is no interoperability necessary for processing that is not defined, so in my implementations I would not change AH from whatever it’s doing today.

Darren,

It's not just interoperability, it's also robustness and security. There is no way we can knowingly allow protocols with non-deterministic behavior in a widely deployed implementation. Implementations need guidance. If IETF does not provide that guidance, then implementations will make up their own rules which is how we end up with de facto standards.

Currently, upstream Linux will treat SRH as routing type 0 for AH ICV. This won't work since there is additional header in SRH and it does not account for TLVs. It is highly unlikely that the interim solution of disallowing SRH+AH would be accepted into Linux unless there is a clear argument that is broken. So Linux needs to be fixed. Unless we get further guidance, I will post a fix that assumes the segment list is unmutable (like HMAC TLV) and assumes that TLV types contain a change bit and are processed just like DO and HBH options are (i.e. only Option Data can be mutable, SR TLVs types and length are immutable, and TLVs can neither be added nor deleted). Is this acceptable?

Tom

Darren

Darren,

Ron,

Tom

                                                    Ron

Juniper Internal

-----Original Message-----
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 24, 2019 1:58 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Ole Troan <[email-masked]<mailto:[email-masked]>>; 6man WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: SRH Mutability and AH

Hi Ron.

Darren

Ole,

                                              Ron

Juniper Internal

-----Original Message-----
From: Ole Troan <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 24, 2019 12:08 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; 6man WG

Ron,

- behavior A
- behavior B
- behavior C"

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Fri, 26 Apr 2019 07:31:42 -0700

Darren,

Sure, that's a bug to fix.

> Now that the bug in Linux AH processing is fixed, and you’ve made no assumptions about AH processing of extension header types that are not defined, you don’t need to make any further changes to AH…

This is about real implementation, not theory. We _have_ to define how
packets with SRH+AH are processed because it is inevitable that an
implementation will receive such packets, and some users will
inevitably configure sending both (as Mark pointed out these are
different layers of functionality that could be set by different
parties using different policies). Again, if this is isn't defined by
standards then implementations will make up their own rules. The
problem with this is that if these ad hoc standards become widely
deployed then that could ossify the protocol; so when IETF gets around
to defining how this is really suppose to work it may be too late for
the standard to have any effect. And if such ossification does occur,
there is NO legitimate claim that what implementations are doing is
non-conformant-- is impossible to be non-conformant with a standard
that is undefined.

In the end, we will be much better of to just define the correct
interaction in the standard now instead of deferring it for
expediency.

Tom

> On Apr 25, 2019, at 11:07 AM, Tom Herbert <[email-masked]> wrote:
>
>
>
> On Thu, Apr 25, 2019, 9:53 AM Darren Dukes (ddukes) <[email-masked]> wrote:
>>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 29 Apr 2019 12:59:40 +0000

Tom, inline.

> On Apr 26, 2019, at 10:31 AM, Tom Herbert <[email-masked]> wrote:
> 
> This is about real implementation, not theory.
Yes, this is about real implementations and real deployments.
Real security software implementations don’t make up their own rules for generating AH ICV for extension headers at source when it is not defined how to do so.
Real deployments of SRv6 (as are happening today around the world) do not use AH with SRH within the SR Domain.
Real use cases for AH with SRH within the SR Domain are not defined.

Given this reality, leaving the text to state AH processing of SRH is not defined is appropriate.

Regardless, the security directorate will advise us further on this and all security related subjects during their review. 

Darren

> We _have_ to define how

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 30 Apr 2019 13:37:02 +0100

Tom Herbert wrote on 26/04/2019 15:31:
> This is about real implementation, not theory. We_have_  to define how
> implementation will receive such packets, [...]

We don't have to define this, but it may be useful to do so.

There are three generalised circumstances where SRH + AH might be an issue:

1. A node inside a domain sending a packet with SRH to another node 
inside the domain

If either of the sending or receiving nodes is a strict router and 
doesn't perform end host functions, this is unlikely to be a serious 
problem because most networks implement a strict division between 
routers and end hosts.  I don't forsee that routers will, in general, 
have a requirement to use AH because implementing ipsec between SRv6 
will, in general, force slow-path packet processing and this is 
something that router operators will, in general, avoid.  This is not a 
blanket statement that router-router traffic with SRH+AH would never 
happen, just an observation that this sort of thing is going to be unusual.

There is one situation to consider for router-router traffic, namely 
OSPFv3 authentication as defined in RFC4522.  I don't think this is an 
issue because ospf neighbours are adjacent to each other, so there is no 
situation where ospfv3 neighbours would need to send packets which 
included an SRH.

If both of the nodes are end hosts, then there could be legitimate 
reasons to want to configure AH between them.  So this comes down to an 
analysis of what sorts of situations would lead to this happening.

If the end host nodes were third party tenants, it is unlikely that the 
network operator would accept packets which included SRH from those 
tenants on the basis that this would end up with the tenants having 
control of packet flow in the network.  Giving second/third parties 
control over how the network operates is something that is actively 
avoided by network operators.

This narrows the use case down to situations where the SRH end host 
nodes are operated within the same administrative domain as the rest of 
the SR domain, and only in situations where the original packet is not 
encapsulated before transport.

2. a node outside the domain sending a packet through an SRv6 domain to 
another node outside the domain.

This case is not relevant because the SRH will be added when it enters 
the domain and stripped when it leaves the domain. From an AH point of 
view, this is a no-op, so requires no further consideration.

3. a node outside the domain sending a packet to a node inside the 
domain, or vice versa.

This scenario is not relevant when the SRv6 domain encapsulates the 
original packet, as the original packet will be preserved intact.  This 
would assume that the packet was encapsulated immediately before being 
sent or decapsulated immediately after being received by the node inside 
the SRv6 domain.

If this is a non-encapsulated SRv6 transport path (e.g. type End), then 
the original header will be affected. For the same reason above, the end 
host inside the SR domain would almost certainly be in the same 
administrative domain as the SR network itself.

In other words, there are at least two situations where SR + AH could 
potentially cause issues.  In each case:

- it would only cause issues for SR configurations which didn't 
encapsulate the original packets

- at least one of the SRv6 end point nodes would be in the same 
administration domain as the SR network itself

Each of these would limit the scope of any failure of the IETF to define 
what happens with AH + SRH.

So instead of updating rfc4302 with a specialised mechanism for handling 
AH + SRH, would it be acceptable to put into the draft:

1. when SRH is used with AH, that this will only work when SRv6 is 
configured to encapsulate the original packet,

2. AH processing on the sender side is done before SR encapsulation

3. AH processing on the receiver side is done after SR decapsulation

4. otherwise AH + SRv6 is undefined.

?

Nick

---

From: Tom Herbert <[email-masked]>
Date: Tue, 30 Apr 2019 07:58:25 -0700

To

> 4. otherwise AH + SRv6 is undefined.
Nick,

Well, we're fifty-four message into this thread and it's amazing to see how
much energy is being spent trying to not define something!

IMO, defining how AH works with SRH should be straightforward. RFC8200 and
RFC4302 provide the necessary guidance on how extension headers interact
with AH: immutable fields are included in ICV calculation, mutable fields
are zeroed, and mutable but predicable fields are adjusted by the sender or
receiver to ensure they both compute ICV over the same bytes.

For SRH this means:

1) The requirements for what header fields are mutable (for any purpose)
need to be clearly articulated. This is important beyond just defining the
interaction with AH. The draft is unclear on this and I have mentioned that
several times without getting any answer. Issue #69 is also about whether
intermediate nodes can add/delete TLVs which is also not clear from the
draft.
2) Extrapolating mutability requirements from the current and previous
drafts gives:
  - Next Header, Hdr Ext Len, Routing Type are immutable (per RFC8200).
  - The destination IP address and the Segments Left field are mutable but
predictable (same as other routing headers)
  - The segment list, flags and other fields are immutable per section
2.1.2.1 that indicates these are immutable for HMAC computation.
  - A change bit in the Option Type indicates that Option Data of a TLV is
mutable. The change bit was present in version -17 of the draft, and
removed in version -18. There were some inconsistencies in the use of the
change bit for -17 compared to HBH and DO that need to be rectified (the
Option Length, Type, and Padding we're not included in ICV calculation
which would seem to imply and intend to add/delete TLVs which is the
subject of issue #69).
3) Given the requirements of mutability, handling of AH in the presence of
SRH can be specified. Procedurally, I believe this could be done as
extending RFC4302.

If there is interest I could provide some suggested text on this.

Tom